Alexander Eisenack hat in der Sommerprüfung 2019 von der IHK Kiel 97% für die Projektpräsentation seiner betrieblichen Projektarbeit bekommen. Herzlichen Glückwunsch zu dieser tollen Leistung!

Alexander war so nett, die Arbeit der Allgemeinheit zur Verfügung zu stellen. Du kannst sie hier herunterladen.

Bewertung

Die Projektpräsentation ist ein sehr gutes Beispiel für eine Projektarbeit. Insbesondere folgende Punkte fallen mir positiv auf:

• Die Vorstellung des Ausbildungsunternehmens wird kurz und knackig auf einer Folie abgehakt.
• Das Projektthema wird gut verständlich erklärt.
• Der Ist-Zustand wird in einem Ablaufdiagramm gut nachvollziehbar dokumentiert.
• Durch den starken Kontrast des dunklen Textes zum weißen Hintergrund und die große Schriftgröße sind alle Folien gut lesbar.
• Neue Projektphasen werden mit entsprechenden Zwischenfolien eingeleitet.
• Die technische Umsetzung wird mit sinnvollen Diagrammen illustriert.
• Es wird ein Screenshot des fertig aufgesetzten Clients gezeigt.

Optimierungspotential

Ein paar Kleinigkeiten sind mir aber auch aufgefallen, um die Arbeit noch zu verbessern.

• Eine Begründung für die ausgewählte Lösung (WDS) fehlt (bzw. eine Betrachtung von Alternativen).
• Viele Folien bestehen nur aus Punktlisten. Hier hätte ich eher Grafiken verwendet.
• Die Kostenrechnung ist quasi nicht vorhanden (keine Zahlen) und auch eine Amortisationsrechnung fehlt mir.
• Auch fehlt mir ein Hinweis auf eine erstellte Dokumentation für die Anwender/Administratoren.
• Die Zeitplanung (Verteilung der 35h) fehlt.

Metadaten

• Titel der Projektarbeit: Erarbeitung und Implementierung einer Lösung zur automatisierten Bereitstellung verschiedener Betriebssysteme mittels PXE-Boots, sowie einer internen Updateverteilungsstelle für Windows Updates
• Ausbildungsberuf: Fachinformatiker Systemintegration
• Prüfung: Sommerprüfung 2019
• Bewertung: 97%
• IHK: IHK Kiel
• Name des Prüflings: Alexander Eisenack
  • Kontaktmöglichkeiten: fachinformatiker.de

Wenn du deine Projektarbeit auch auf dieser Seite veröffentlichen möchtest, dann sprich mich gerne an. Ich suche (sehr gute) Beispiele aus allen IT-Berufen.

Download

Vielen Dank an Alexander Eisenack für das Bereitstellen der Projektpräsentation. Alle internen Angaben oder personenbezogenen Daten wurden entweder unkenntlich gemacht oder durch fiktive Werte ersetzt.

• Projektpräsentation Fachinformatiker Systemintegration von Alexander Eisenack (PDF) (IHK Kiel, Sommerprüfung 2019)
  
• Projektpräsentation Fachinformatiker Systemintegration von Alexander Eisenack (PPTX)

Weitere Infos zur Projektpräsentation

Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.

Der Beitrag Projektpräsentation im Bereich Systemintegration von Alexander Eisenack (mit 97% bewertet) erschien zuerst auf IT-Berufe-Podcast.

Um Möglichkeiten, Abhängigkeiten in Tests loszuwerden, geht es in der einhundertdreiundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Vorweg: Automatisierte Tests gibt es nicht nur für objektorientierte Software, sondern natürlich auch für funktionale, prozedurale usw. Die folgenden Inhalte beziehen sich aber ausschließlich auf die Objektorientierung. In anderen Paradigmen haben die genannten Begriffe evtl. andere Bedeutungen oder die vorgestellten Lösungen funktionieren etwas anders, da es z.B. keine Polymorphie gibt.

Grundlagen

• Automatisierte Tests sollen das Verhalten unseres Systems prüfen und nur fehlschlagen, wenn ein Fehler im Code vorliegt. Sie sollen schnell und wiederholbar sein, damit sie so oft wie möglich ausgeführt werden. Sie sollen immer und überall (auf allen Rechnern/Umgebungen) ausführbar sein.
• Unit-Tests prüfen das Verhalten einer einzelnen Komponente, z.B. eine Methode, in Isolation.
• Integrationstests prüfen das Verhalten mehrerer Komponenten, z.B. Objekte, im Zusammenspiel.
• Integrationstests werden auch Tests genannt, die die Infrastruktur berühren, also z.B. eine Datenbank, das Netzwerk oder das Dateisystem.
• Die Infrastruktur sollte in Tests nicht berührt werden, da diese schnell Fehler produziert: erwartete Datenbankinhalte können sich ändern, im Dateisystem fehlen Berechtigungen oder das Netzwerk ist nicht verfügbar.
• Die Isolation von Komponenten ist schon in kleinen Systemen nicht immer einfach. Ein Objekt kann seine Aufgaben fast nie komplett allein erledigen, sondern braucht andere Objekte dafür. Ein Service braucht vielleicht ein Repository, um die zu verarbeitenden Daten aus der Datenquelle zu lesen. Ist kein Repository vorhanden, gibt es vielleicht eine NullPointerException beim Aufruf der zu testenden Methode.
• Diese Abhängigkeiten machen die Tests schwierig, da das zu testende Objekt nicht korrekt funktioniert, wenn sie nicht vorhanden sind. Somit müssen alle für den konkreten Test benötigten Abhängigkeiten durch diesen bereitgestellt werden.
• Somit enthält ein Test nicht nur die eigentlich zu testende Komponente, sondern auch noch ihre Abhängigkeiten. Damit klar ist, welche der verschiedenen Komponenten nun eigentlich getestet werden soll, bekommt sie die Bezeichnung System under test (abgekürzt SUT).
• Beim Test können grundsätzlich die „echten“ Komponenten verwendet werden, falls dies möglich und sinnvoll ist. Oder die Komponenten werden durch sog. Test Doubles ersetzt, wie ein Stuntdouble den eigentlichen Schauspieler ersetzt.

Test Doubles

• Test Doubles sind der Oberbegriff für Komponenten, die in Tests verwendet werden, um die Abhängigkeiten des SUT zu ersetzen. Sie sollen vor allem für vorhersagbare Testergebnisse sorgen, indem z.B. immer die gleichen Werte aus dem Speicher zurückgegeben werden und nicht potentiell unterschiedliche Werte aus der Datenbank gelesen werden.
• Damit das Ganze funktioniert, müssen die echten Komponenten durch die Test Doubles ersetzt werden können. In objektorientierter Software kommt dabei die Polymorphie zum Einsatz. Die Abhängigkeiten müssen also z.B. als Interface oder als (abstrakte) Basisklasse vorliegen, damit die Test Doubles anstelle der echten Komponenten genutzt werden können.
• Außerdem ist es nötig, dass die Test Doubles dem SUT „untergejubelt“ werden können. Es ist also irgendeine Form von Dependency Injection nötig, z.B. Konstruktorparameter oder Setter-Methoden. Sobald das SUT sich selbst seine Abhängigkeiten erzeugt (z.B. mit new), ist ein Test mit Test Doubles schwierig oder gar unmöglich.
• Das alles hat auch eine Auswirkung auf den Produktivcode. Denn wenn das SUT eine Abhängigkeit als Konstruktorparameter übergeben bekommen muss, wird auch der Produktivcode die echte Komponente so hineingeben müssen.
• Die Tests haben somit indirekt zur Folge, dass der Code insgesamt modularer wird, was die Softwarequalität erhöht.
• Zum Erstellen von Test Doubles gibt es verschiedene Frameworks, z.B. Mockito in Java oder Moq für .NET.

Fakes

• Fakes (engl. fake = Fälschung, Imitation) können ohne Framework einfach selbst implementiert werden.
• Ihre Implementierung ähnelt der echten, ist aber z.B. einfacher/schneller oder gibt nur harte Werte zurück.
• Beispiel: InMemory-Datenbank statt einer echten verwenden.

Dummy

• Dummies (engl. dummy = Attrappe, Strohmann) sind Platzhalter, deren Funktion im Test eigentlich gar nicht benötigt wird.
• Sie werden verwendet, um den Compiler zufriedenzustellen, da z.B. ein Objekt als Parameter erwartet wird.
• Wenn die Funktionalität wirklich überhaupt nicht verwendet (=aufgerufen) wird, kann auch null verwendet werden.

Stubs

• Stubs (engl. stub = Stummel, Stumpf) geben auf Anfragen definierte (=harte) Werte zurück, um das Verhalten des SUT vorhersagbar zu machen oder teure und fehleranfällige Zugriffe auf die Infrastruktur zu vermeiden. Außerdem dienen sie dazu, ansonsten schwer zu produzierende Zustände abzubilden, z.B. das Werfen einer Exception.
• Stubs werden für in das SUT eingehende Daten verwendet.
• Beispiel: Ein Repository gibt dem SUT immer den gleichen Datensatz zurück, ohne auf die Datenbank zuzugreifen.
• Das Verhalten kann parametrisiert werden, z.B. für ID 1 ein bestimmter Datensatz und für andere IDs eine Exception.
• Beispiel in Mockito: when(repo.getUser(1)).thenReturn(new User("Stefan"));
• Einsatzgebiete: Dateisystem, DB, Netzwerk usw.
• Teilt man die Methodenaufrufe seines Systems in Queries (nur lesen, keine Zustandsänderung, Rückgabewert) und Commands (Zustandsänderung, kein Ergebnis als Rückgabewert) auf, verwendet man Stubs für die Queries.
• Die Tests verwenden „normale“ Assertions, um das Ergebnis des SUT zu prüfen (assert in JUnit).

Mocks

• Mocks (engl. mock = Fäschung, Nachahmung) „merken“ sich die Methodenaufrufe an ihnen und können im Nachhinein verifizieren, ob ein Methodenaufruf stattfand, wie oft und mit welchen Parametern.
• Mocks werden für aus dem SUT ausgehende Befehle verwendet.
• Beispiel: Das SUT soll eine Mail verschicken und dafür am MailServer die Methode send() mit bestimmten Parametern (z.B. Adresse, Betreff) aufrufen.
• Oftmals müssen die Mocks auch Daten zurückgeben, damit das SUT funktioniert. Eigentlich sollten sie das aber nicht tun. Dies weist auf eine Vermischung von Command und Query hin.
• Beim Command-Query-Pattern, verwendet man Mocks für die Commands.
• Die Tests verwenden keine Assertions gegen das SUT, sondern prüfen am Mock, ob die richtigen Methoden aufgerufen wurden (verify in Mockito).
• Beispiel in Mockito: verify(mailServer).send("stefan@macke", "Hallo Stefan!");

Spy

• Spies (engl. spy = Spion) sind nicht eindeutig definiert.
• Ein Spy kann ein Stub mit „Aufzeichnungsfunktion“ der Interaktionen (ähnlich zum Mock) sein (siehe Test Double).
• In Mockito ist ein Spy eine Art Mock zur Aufzeichnung der Interaktionen, aber mit der Möglichkeit der Delegation der Aufrufe an die echte Komponente (siehe Spy). Der Spy „umschließt“ also das echte Objekt, kann einzelne Methoden überschreiben und delegiert den Rest an das echte Objekt. Im Nachhinein kann dann noch geprüft werden, welche Methoden aufgerufen wurden.

Vor- und Nachteile von Test Doubles

• Vorteile
  • Tests sind nicht abhängig von änderungsanfälliger Infrastruktur.
  • Tests sind einfacher, da keine komplexe Infrastruktur aufgebaut werden muss.
  • Tests lassen sich jederzeit und überall wiederholbar durchführen.
  • Tests sind schneller, da keine Infrastruktur berührt wird.
  • Der Code wird modularer und Abhängigkeiten werden offensichtlich.
• Nachteile
  • Das Zusammenspiel der „echten“ Komponenten wird nicht getestet. Es sind zusätzliche Integrationstests nötig.
  • Das einfache Erstellen von Test Doubles mit Frameworks führt ggfs. zu komplexen Test-Setups oder Overengineering.

Allgemeine Hinweise und Empfehlungen

• Viele Frameworks (u.a. Mockito) unterscheiden nicht zwischen Stub und Mock. Die erzeugten Test Doubles können sowohl feste Ergebnisse liefern als auch die Interaktion mit ihnen aufzeichnen. Die Unterscheidung liegt also allein darin, wie das Test Double im Test verwendet wird.
• Grundsätzlich sollte immer die echte Implementierung im Test bevorzugt werden, bevor Test Doubles genutzt werden, da somit gleich mehrere „echte“ Komponenten des Systems mitgetestet werden und insb. auch deren Interaktion.
• Zugriffe auf die Infrastruktur, die die Tests langsam und fehleranfällig machen, sollten immer durch Test Doubles ersetzt werden.
• Tests, die ausschließlich mit Test Doubles arbeiten, reichen nicht aus, um die Funktionalität des Gesamtsystems zu gewährleisten. Es sind dann weitere Integrationstests mit den echten Komponenten nötig.
• Wenn das Setup der Test Doubles zu umständlich wird (z.B. Doubles, die Doubles zurückgeben, die Doubles zurückgeben), sollte man das Design seiner Komponenten überdenken (z.B. Law of Demeter).

Literaturempfehlungen

Zum Einstieg in Unit-Tests inkl. Mocking kann ich sehr Pragmatic Unit Testing in Java 8 with JUnit* von Jeff Langr empfehlen. Das Buch lesen meine Azubis bereits im 1. Ausbildungsjahr und ich habe auch schon eine Podcast-Episode dazu aufgenommen: Pragmatic Unit Testing in Java 8 with JUnit (Buchclub).

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Test Double
• Mocks Aren’t Stubs
• Test Doubles — Fakes, Mocks and Stubs.

Der Beitrag Mocks, Stubs, Fakes, Dummies und Test Doubles – Anwendungsentwickler-Podcast #143 erschien zuerst auf IT-Berufe-Podcast.

Timo Teschke hat in der Sommerprüfung 2019 von der IHK Oldenburg 100% für die Projektpräsentation seiner betrieblichen Projektarbeit bekommen. Herzlichen Glückwunsch zu dieser tollen Leistung!

Timo war so nett, die Arbeit der Allgemeinheit zur Verfügung zu stellen. Du kannst sie hier herunterladen.

Bewertung

Die Projektpräsentation ist ein sehr gutes Beispiel für eine Projektarbeit. Insbesondere folgende Punkte fallen mir positiv auf:

• Die Projektarbeit hat ein modernes und anspruchsvolles Thema: die Entwicklung einer Augmented-Reality-Plattform. Sicherlich (noch) ein außergewöhnliches Thema.
• Das Thema ist nachvollziehbar erläutert und gut begründet.
• Es werden mehrere Programmiersprachen verwendet, um das Projekt umzusetzen, was die Komplexität unterstreicht.
• Die Architektur der Anwendung inkl. verwendeter Komponenten wird verständlich dargestellt.
• Es werden viele passende Methodiken (Klassendiagramm, ERM usw.) angewendet und die Software wird professionell entwickelt.
• Zu jeder Projektphase wird das passende Artefakt (Use-Cases, Pflichtenheft usw.) erwähnt und (in Ausschnitten) gezeigt.
• Der Prozess bei Datenbankanpassungen („Migrations“) wird erläutert (Continuous Integration).
• Es wird auch Quelltext (in verschiedenen Sprachen) gezeignet.

Optimierungspotential

Ein paar Kleinigkeiten sind mir aber auch aufgefallen, um die Arbeit noch zu verbessern.

• Für den (selbst berechneten) Stundensatz werden nur die Gehälter berücksichtigt und keine Lohnnebenkosten.
• Im Use-Case-Diagramm fehlen die Extension Points.
• Zur Dokumentation des Unity-Codes wird ein Struktogramm verwendet anstatt einer modernen Darstellungsform (z.B. UML).
• Die einzelnen Projektphasen mit Zeitplanung werden nicht gezeigt.
• Die fertige Anwendung wird nicht gezeigt (z.B. als Screenshot).

Metadaten

• Titel der Projektarbeit: AR-Plattform – Entwicklung einer Augmented Reality Plattform
• Ausbildungsberuf: Fachinformatiker Anwendungsentwicklung
• Prüfung: Sommerprüfung 2019
• Bewertung: 100%
• IHK: IHK Oldenburg
  • Vorgaben der IHK Oldenburg: Max. 15 Seiten Inhalt + 25 Seiten Anhang.
• Name des Prüflings: Timo Teschke
  • Kontaktmöglichkeiten: LinkedIn, Xing
• Ausbildungsbetrieb: Quantumfrog
  • Kontaktmöglichkeiten: Website

Wenn du deine Projektarbeit auch auf dieser Seite veröffentlichen möchtest, dann sprich mich gerne an. Ich suche (sehr gute) Beispiele aus allen IT-Berufen.

Download

Vielen Dank an Timo Teschke und Quantumfrog für das Bereitstellen der Projektpräsentation. Alle internen Angaben oder personenbezogenen Daten wurden entweder unkenntlich gemacht oder durch fiktive Werte ersetzt.

• Projektpräsentation Fachinformatiker Anwendungsentwicklung von Timo Teschke (IHK Oldenburg, Sommerprüfung 2019)
  

Weitere Infos zur Projektpräsentation

Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.

Der Beitrag Projektpräsentation von Timo Teschke (mit 100% bewertet) erschien zuerst auf IT-Berufe-Podcast.

Wir gehen ein komplettes Beispiel zur Normalisierung einer relationalen Datenbank durch in der einhundertvierundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

Theoretische Grundlagen

• Wir normalisieren Datenbanken um Redundanzen zu vermeiden, die zu Anomalien führen können. Mehr dazu in Podcast-Episode 18.
• Grundlagen wie Schlüssel, Kardinalitäten usw. erkläre ich in Podcast-Episode 17.
• Merksatz: „The key, the whole key, and nothing but the key.“

Beispieldaten

Wir verwenden ein „klassisches“ Beispiel, das so oder ähnlich in vielen IHK-Prüfungen genutzt wird.

• Umfeld: Kunden bestellen Artikel aus verschiedenen Artikelgruppen.
• Ein Kunde kann mehrere Bestellungen durchführen. Eine Bestellung wird immer von genau einem Kunden getätigt.
• Zu den Kunden werden Name und Adresse erfasst.
• Jede Bestellung hat ein Bestelldatum.
• In einer Bestellung können mehrere Artikel enthalten sein. Ein Artikel kann auch in mehreren Bestellungen auftauchen.
• Artikel haben eine Bezeichnung und einen Preis.
• Ein Artikel kann zu genau einer Artikelgruppe gehören. Eine Artikelgruppe kann mehrere Artikel enthalten.
• Artikelgruppen haben eine Bezeichnung und einen Rabatt.

Ausgangssituation (nicht normalisiert)

• Alle Bestellungen stehen in einer einzelnen Tabelle. Jede Bestellung steht komplett inkl. mehrerer Artikel in einer Zeile. Die Adresse steht komplett in einem einzigen Attribut.
• Beispiele für Probleme: Viele Redundanzen (z.B. Adressen, Artikelbezeichnungen), Sortierung nach Ort ist nicht möglich, Selektion aller gekaufter Fernseher ist nicht möglich.

1. Normalform

• Definition: Es gibt 1) nur atomare Attribute und 2) keine Wiederholungsgruppen.
• „the key“: Alle Datensätze sind eindeutig über einen Primärschlüssel identifizierbar.
• Durch 2) werden Redundanzen zunächst eingeführt, da aus einer Zeile nun mehrere Zeilen mit redundanten Inhalten werden.
• Vorgehen: Nicht-atomare Attribute auf mehrere Spalten aufteilen. Wiederholungsgruppen auf mehrere Zeilen aufteilen.
• Ein Datensatz ist über einen zusammengesetzten Schlüssel aus drei Attributen identifizierbar.
• Redundanzen: Kunden-, Bestell- und Artikeldaten sind jeweils mehrfach vorhanden.
• Ursache: Tabelle enthält drei Konzepte (Kunde, Bestellung, Artikel), die alle nur von Teilen des Schlüssels abhängen und nicht vom gesamten.

2. Normalform

• Definition: (1. Normalform erfüllt und) alle Attribute sind voll funktional vom Primärschlüssel abhängig.
• „the whole key“: Alle Attribute hängen vom gesamten Schlüssel ab (und nicht nur von seinen Teilen).
• Vorgehen: Alle drei Konzepte auf einzelne Tabellen aufteilen. Fremdschlüssel für Referenzen einführen. Zuordnungstabelle Position mit zusammengesetztem Schlüssel aus Fremdschlüsseln einführen.
• m:n-Beziehungen werden aufgelöst.
• Menge gehört an die Kombination aus Bestellung und Artikel und weder an das eine noch das andere allein.
• Redundanzen: Artikelgruppe und Rabatt gehören zusammen und sind mehrfach vorhanden.
• Ursache: Rabatt hängt von Artikelgruppe ab und nicht von der Artikelnummer (=transitive Abhängigkeit).

3. Normalform

• Definition: (2. Normalform erfüllt und) es gibt keine transitiven Abhängigkeiten.
• „and nothing but the key“: Kein Nicht-Schlüssel-Attribut hängt von einem anderen Nicht-Schlüssel-Attribut ab.
• Vorgehen: Artikelgruppe in eigene Tabelle extrahieren und Fremdschlüssel für Referenz einführen.
• 1:n-Beziehungen werden aufgelöst.

Ergebnis

• Jede Tabelle enthält genau ein Konzept.
• Keine Daten sind mehr redundant.
• In jeder Tabelle gibt es einen eindeutigen Primärschlüssel.
• Fremdschlüssel werden für Referenzen auf Datensätze in anderen Tabellen verwendet.

Literaturempfehlungen

Zum Einstieg ins Thema Datenbanken inkl. Modellierung, Normalisierung und SQL empfehle ich Einstieg in SQL* von Michael Laube.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Relationale Datenbanken – Häufige Fragen im Fachgespräch
• Normalisierung – Häufige Fragen im Fachgespräch
• Normalisierung (Datenbank)

Der Beitrag Normalisierung einer Datenbank am konkreten Beispiel – Anwendungsentwickler-Podcast #144 erschien zuerst auf IT-Berufe-Podcast.

Die Fortsetzung zum Oberthema Kryptographie mit Zertifikaten und Zertifizierungsstellen gibt es in der einhunderfünfundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Wiederholung: Für die elektronische Signatur und die Verschlüsselung von Daten werden Paare aus öffentlichen und privaten Schlüsseln benötigt.
• Probleme
  • Wer garantiert dem Absender, dass ein öffentlicher Schlüssel auch wirklich dem angegebenen Empfänger gehört?
  • Wie kann sichergestellt werden, dass ein öffentlicher Schlüssel nicht von einem Angreifer durch seinen eigenen ausgetauscht wurde?
• Zertifikat
  • Mit einem Zertifikat bestätigt eine unabhängige dritte Partei die Echtheit des öffentlichen Schlüssels des Empfängers. Diese dritte Partei wird Zertifizierungsstelle genannt.
  • Die Zertifizierungsstelle (englisch Certificate Authority, abgekürzt CA) bestätigt die Authentizität des Schlüssels des Empfängers, indem sie z.B. dessen Adresse und Identität prüft.
  • Das kostet meistens Geld, je nachdem wie intensiv diese Prüfung gemacht wird. Das geht von „muss eine E-Mail-Adresse mit dieser Domain abrufen können“ bis hin zu „das Unternehmen existiert tatsächlich unter der postalischen Adresse“.
  • Wenn Alice statt dem öffentlichen Schlüssel von Bob ein Zertifikat erhält, kann sie es wiederum mit dem Zertifikat der CA prüfen. Sie weiß nun sicher, dass sie den korrekten öffentlichen Schlüssel nutzt und nicht einen kompromittierten.
  • Alice muss dafür allerdings dem Zertifikat der Zertifizierungsstelle selbst vertrauen, da auch diese kompromittiert werden kann. Es entsteht also eine Vertrauenskette, die irgendwo in einem Root-Zertifikat endet. Und diesem Zertifikat muss manuell vertraut werden.
  • Das „Urvertrauen“ in die verschiedenen CAs wird hergestellt, indem sie z.B. in Browser wie Firefox oder Chrome vom Hersteller fest „eingebaut“ und als vertrauenswürdig gekennzeichnet werden.
  • Sollte ein Zertifikat kompromittiert werden, gibt es sog. Certificate Revocation Lists (CRL), in die die nicht mehr validen Zertifikate eingetragen werden können. Dafür müssen diese Listen aber natürlich bei jeder Prüfung eines Zertifikats kontrolliert werden, was sehr aufwändig ist.
• Technische Umsetzung
  • Zertifikate sind (Plain-Text-)Dateien, die verschiedene technische Informationen enthalten wie z.B. den Namen des Ausstellers, den zertifizierten öffentlichen Schlüssel des Empfängers, ein Ablaufdatum, die elektronische Signatur der ausstellenden CA.
  • Vereinfacht (!) gesagt, ist das Zertifikat der mit dem privaten Schlüssel der CA signierte öffentliche Schlüssel des Empfängers. Nur mit dem öffentlichen Schlüssel der CA kann diese Signatur geprüft werden. Und dieser öffentliche Schlüssel ist für alle wichtigen CAs im Browser hinterlegt.
  • Genauer gesagt werden alle Inhalte des Zertifikats signiert und vom öffentlichen Schlüssel des Empfängers nur der Hash. Und im Browser sind auch nicht nur die öffentlichen Schlüssel der CAs hinterlegt, sondern wiederum Zertifikate, die wiederum zertifizert sind usw.
  • Die Root-Zertifikate am Ende dieser Kette werden dann von der CA selbst signiert und heißen selbstsignierte Zertifikate. Dabei garantiert quasi die CA selbst, dass sie wirklich diese CA ist.
    
  • Der Aufbau der Dateien ist standardisiert, z.B. im Format X.509.
  • Aussteller und Zertifikatinhaber werden durch eine Reihe von Attributen beschrieben, z.B. den sog. Common Name (CN), Land und Ort.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Public-Key-Zertifikat
• X.509
• Zertifikatsperrliste

Der Beitrag Kryptographie – Zertifikate und Zertifizierungsstellen – Anwendungsentwickler-Podcast #145 erschien zuerst auf IT-Berufe-Podcast.

Zum Abschluss meiner kleinen Reihe zum Oberthema Kryptographie widmen wir uns der Funktionsweise von HTTPS in der einhundersechsundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Wiederholung
  • Für die elektronische Signatur und die Verschlüsselung von Daten werden Paare aus öffentlichen und privaten Schlüsseln benötigt.
  • Um die Authentizität öffentlicher Schlüssel zu gewährleisten, werden Zertifikate verwendet, die von vertrauenswürdigen Zertifizierungsstellen ausgegeben werden.
• Probleme
  • Wie können wir bei Millionen verschiedenen Websites sicherstellen, dass sie korrekte Schlüssel nutzen, ohne dass wir alle Websitebetreiber persönlich kennen müssen?
  • Wie kann bei den großen Datenmengen im Internet eine performante Verschlüsselung gewährleistet werden?
• HTTPS
  • Um mit einem Webserver verschlüsselt kommunizieren zu können, benötigt der Webbrowser den öffentlichen Schlüssel des Webservers.
  • Diesen kann er einfach direkt vom Webserver selbst herunterladen. Aber wer garantiert ihm die Echtheit dieses Schlüssels? Vielleicht wurde der Server gehackt oder der private Schlüssel gestolen.
  • Deswegen liefert der Webserver nicht direkt den öffentlichen Schlüssel aus, sondern ein von einer CA ausgestelltes Zertifikat, das den öffentlichen Schlüssel des Webservers enthält, aber zusätzlich noch die Signatur der CA, die dessen Echtheit bestätigt.
  • Wenn dieses Zertifikat gültig ist (die Prüfung erfolgt gegen die „eingebauten“ CAs im Browser), weiß der Browser sicher, dass er den korrekten Schlüssel erhalten hat und kann ihn für die Verschlüsselung nutzen.
    
  • Dabei prüft der Browser auch, ob das Zertifikat zur aktuellen Domain gehört. Der CN enthält bei HTTPS-Zertifikaten diese Domain.
  • Es gibt seit einiger Zeit auch eine kostenlose CA: Let’s Encrypt. Damit kann sich jeder Webserverbetreiber gültige Zertifikate erzeugen, indem er technisch nachweist, dass die Domain und der Server wirklich ihm gehören.
    
  • Der Datenverkehr wird bei HTTPS symmetrisch verschlüsselt, da die Schlüssellängen hierbei deutlich kürzer sind, was deutliche Performancevorteile hat. Um diesen Schlüssel zwischen Browser und Webserver auszutauschen wird das obige asymmetrische Verfahren genutzt. Deswegen ist HTTPS ein hybrides Verfahren.
• Technischer Ablauf
  • CA
    • CA generiert privaten und öffentlichen Schlüssel.
    • CA erstellt selbstsigniertes Root-Zertifikat: ihr eigener öffentlicher Schlüssel signiert mit ihrem privaten Schlüssel.
    • CA-Root-Zertifikat wird in Browser eingebaut.
  • Webserver
    • Webserver generiert privaten und öffentlichen Schlüssel.
    • Webserver lässt öffentlichen Schlüssel von CA mit ihrem privaten Schlüssel signieren.
    • Webserver installiert dieses Zertifikat und konfiguriert HTTPS.
  • Browser
    • Browser öffnet Website auf dem Webserver.
    • Webserver liefert sein Zertifikat aus.
    • Browser prüft das Zertifikat mit dem öffentlichem Schlüssel der CA aus seinem eingebautem Root-Zertifikat und erhält den öffentlichen Schlüssel des Webservers.
    • Browser generiert einen zufälligen temporären Sitzungsschlüssel und verschlüsselt ihn mit dem öffentlichen Schlüssel des Webservers.
    • Browser sendet den verschlüsselten Sitzungsschlüssel an den Webserver, der ihn mit seinem privaten Schlüssel entschlüsselt.
    • Nun kennen Browser und Webserver den Sitzungsschlüssel und können damit symmetrisch den Datenverkehr verschlüsseln.
• Mögliche Probleme mit HTTPS-Zertifikaten
  • Das Zertifikat ist abgelaufen.
  • Das Zertifikat passt nicht zur Domain.
  • Das Zertifikat wurde von einer nicht vertrauenswürdigen CA ausgestellt.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Hypertext Transfer Protocol Secure
• Wie funktioniert https?
• Einführung inOpenSSL und X.509-Zertifikate
• Let’s Encrypt
• Certificate Signing Request

Der Beitrag Kryptographie – Funktionsweise von HTTPS – Anwendungsentwickler-Podcast #146 erschien zuerst auf IT-Berufe-Podcast.

Um Code Smells und ihre Behebung mittels Refactorings geht es in der einhundertsiebenundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Was ist ein Code Smell?
  • Smells sind Indikatoren für Code, der überarbeitungswürdig ist.
  • Man erkennt sie anhand verschiedener Muster (z.B. lange Methoden).
  • Die Smells können mit Refactorings überarbeitet und (hoffentlich) eliminiert werden.
  • Nicht alle Smells sind immer schlecht. Sie dienen nur als Anhaltspunkt, noch einmal über den Code nachzudenken.
• Woher kommt der Name Code Smell?
  • Kent Becks Oma wird das Zitat „If it stinks, change it.“ zugesprochen, das sich auf das Wechseln von Windeln bei Babys bezieht.
  • Kent Beck hat diese Idee auf Code übertragen: Wenn der Code seltsam „riecht“, sollte man ihn anpassen.
• Wobei helfen uns Code Smells?
  • Mit Code Smells können wir Stellen im Code aufdecken, die problematisch sind, und diese überarbeiten. Dadurch wird der gesamte Code insgesamt „besser“.
  • Die benannten Smells helfen uns durch eine gemeinsame Sprache bei der Diskussion mit anderen Entwicklern (ähnlich wie Design Pattern).
• Was können wir gegen Code Smells tun?
  • Das Mittel gegen Code Smells sind die Refactorings.
  • Im Buch von Martin Fowler* gibt es eine übersichtliche Tabelle, welche Refactorings gegen welche Smells helfen können.
• Sind Code Smells immer böse?
  • Code Smells sind nur ein Anhaltspunkt für Optimierungen. Der Entwickler muss selbst entscheiden, ob der Smell schlecht ist.
  • Einige Code Smells hängen zusammen und das Auflösen des einen (z.B. Introduce Parameter Object) führt zur Einführung eines anderen (z.B. Data Class).
• Welche Code Smells gibt es?
  • Duplicate Code
    • Doppelter Code führt bei Änderungen schnell zu Fehlern, weil zu ändernde Stellen übersehen werden.
    • Refactorings: Extract Method, Pull Up Method
  • Comments
    • Kommentare können helfen, den Code zu verstehen, aber häufig sind sie überflüssig und können durch sprechendere Bezeichner komplett eliminiert werden.
    • Refactorings: Extract Method, Rename Method
  • Long Method
    • Lange Methoden sind schwieriger zu verstehen, zu testen und anzupassen.
    • Refactorings: Extract Method
  • Large Class
    • Zu große Klassen machen häufig mehr als sie sollen und verletzen das Single Responsibility Principle. Das macht sie u.a. schwer testbar.
    • Refactorings: Extract Class, Extract Subclass
  • Long Parameter List
    • Viele Parameter bei Methoden deuten darauf hin, dass diese zu viele Aufgaben übernehmen. Sie machen die Methoden schwer testbar und schwer verständlich. Außerdem müssen die Parameterlisten tendenziell oft angepasst werden.
    • Refactorings: Replace Parameter with Method, Introduce Parameter Object
  • Feature Envy
    • Wenn Methoden oder Klassen sich viele Informationen „besorgen“ müssen, bevor sie ihren Job machen können, ist das ein Zeichen dafür, dass die Komponenten besser an einer anderen Stelle aufgehoben wären.
    • Refactorings: Move Method
  • Data Clumps
    • Wenn verschiedene Daten immer zusammen herumgereicht werden (z.B. Startdatum und Endedatum), ist das ein Zeichen für eine fehlende Abstraktion (z.B. Zeitraum).
    • Refactorings: Introduce Parameter Object, Extract Class
  • Primitive Obsession
    • Die Scheu vor eigenen kleinen Klassen führt oft dazu, dass doppelter Code entsteht und eine gute Kapselung verhindert wird.
    • Refactorings: Replace Data Value with Object, Extract Class, Introduce Parameter Object
  • Switch Statements: Gleiche Fallunterscheidungen werden häufig an mehreren Stellen benötigt und führen zu doppeltem Code, der mit Polymorphie verhindert werden könnte.
  • Divergent Change: Einzelne Klassen müssen aufgrund von verschiedenen Änderungen angepasst werden.
  • Shotgut Surgery: Aufgrund einer einzelnen Änderung müssen verschiedene Klassen angepasst werden.
  • Parallel Inheritance Hierarchies: Sonderform von Shotgun Surgery, die das parallele Anlegen von Subklassen in verschiedenen Hierarchien erfordert.
  • Lazy Class: Zu kleine Klassen, die keinen erkennbaren Mehrwert haben, sollten abgelöst werden.
  • Speculative Generality: Anstatt alle möglichen zukünftigen Entwicklungen zu antizipieren, sollte besser das Prinzip You Ain’t Gonna Need It befolgt werden.
  • Temporary Field: Instanzvariablen sollten nicht nur während der Laufzeit einzelner Methoden verwendet werden.
  • Message Chains: Objekte, die Objekte aufrufen, die wieder Objekte aufrufen, wissen zu viel über die fremde Implementierung und sind damit stark gekoppelt. Das verletzt das Law of Demeter.
  • Middle Man: Zu viel Delegierung ist auch nicht gut.
  • Inappropriate Intimacy: Klassen sollten nicht zu viele Details anderer Klassen kennen.
  • Alternative Classes with Different Interfaces: Gleiche Dinge sollten auch gleich benannt sein.
  • Incomplete Library Class: Wenn Librarys nicht alles tun, was wir brauchen, sollten wir sie ergänzen, anstatt alles neu zu entwickeln.
  • Data Class: Die guten alten POJOs oder Java Beans. Sie verhindern häufig saubere Kapselung und haben bei fehlender Geschäftslogik evtl. gar keine Daseinsberechtigung.
  • Refused Bequest: Wenn Subklassen Teile ihres Vermächtnisses (geerbte Member) nicht nutzen wollen oder können, ist vielleicht die Hierarchie falsch gewählt.

Literaturempfehlungen

Eine sehr schöne Liste möglicher Code Smells und ihrer Auswirkungen gibt es im Klassiker Refactoring von Martin Fowler*.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Code Smells
• Catalog of Refactorings
• Refactoring and Design Patterns

Der Beitrag Code Smells und Refactorings – Anwendungsentwickler-Podcast #147 erschien zuerst auf IT-Berufe-Podcast.

Um die Handelskalkulation inkl. Skonto und Rabatt geht es in der einhundertachtundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Käufer zahlen immer so spät wie möglich ihre Rechnungen, da sie in der Zwischenzeit mit ihrem Geld andere Dinge machen können (z.B. verzinslich anlegen).
• Verkäufer wollen das Geld aber so früh wie möglich haben, da sie bereits in Vorleistung gegangen sind.
• Ein übliches Zahlungsziel bei Rechnungen ist 30 Tage. Das würde ein Käufer immer ausnutzen.
• Damit der Käufer schneller zahlt, kann der Verkäufer Skonto gewähren, wenn z.B. bereits bis zum 10. Tag gezahlt wird. Übliche Skontosätze sind 2% oder 3%.
• Ein Rabatt ist ein allgemeiner Preisnachlass des Verkäufers.
• Käufer ziehen sich Rabatt und Skonto (in dieser Reihenfolge) vom ihnen angebotenen Preis ab („vom Hundert“).
  • Beispiel: PC kostet 1.000 EUR. 10% Rabatt ergeben einen Abzug von 100 EUR.
• Verkäufer müssen Skonto und Rabatt (in dieser Reihenfolge) auf ihre Preise aufschlagen („im Hundert“), damit sie nicht zu ihren Ungunsten abgezogen werden. Die Basis 100% ist dabei der zu errechnende Preis und nicht der, auf den aufgeschlagen wird.
  • Beispiel: PC soll für 1.000 EUR verkauft werden. Der Kunde soll 10% Rabatt abziehen können dürfen. 1.000 EUR entsprechen dabei 90%, der gesuchte Zielpreis 100%. Mittels Dreisatz ergibt sich ein Preis von 1.111,11 EUR (und nicht etwa 1.100 EUR!). 10% Abzug von 1.111,11 EUR sind 111,11 EUR, sodass der ursprünglich gewünschte Preis von 1.000 EUR beim Händler landet.

Handelskalkulation

• Mittels der Handelskalkulation berechnen Handelsunternehmen ihre Verkaufspreise auf Basis der Einkaufspreise bei ihren Lieferanten.
• In produzierenden Unternehmen oder bei Dienstleistern wird ggfs. anders kalkuliert, z.B. mittels des Betriebsabrechnungsbogens bzw. eines Stundensatzes.

So sieht eine vollständige Handelskalkulation aus:

   Listeneinkaufspreis (steht beim Lieferanten auf dem Preisschild)
− Lieferantenrabatt (handelt ein vernünftiger Kunde vom Preis runter)
= Zieleinkaufspreis (müsste der Kunde bei Zahlung auf Rechnung am 30. Tag überweisen)
− Lieferantenskonto (zieht der Kunde ab, wenn er schneller zahlt, z.B. bis zum 10. Tag)
= Bareinkaufspreis (müsste der Kunde „bar“ auf den Tisch legen, um das Produkt mitzunehmen)
+ Bezugskosten (ggfs. Porto, Spedition)
= Bezugspreis (zahlt der Kunde, damit das Produkt „bei ihm auf dem Hof“ steht)
+ Handlungskosten (alle Kosten für den Geschäftsbetrieb, z.B. Miete, Strom, Gehälter usw.)
+ Lagerzins (falls Waren eingelagert werden müssen)
= Selbstkostenpreis (hiermit sind alls Kosten des Händlers abgedeckt)
+ Gewinn (das bleibt am Ende dem Händler übrig)
= Barverkaufspreis (das müsste der Kunde bar bezahlen, um alle Kosten + Gewinn des Händlers zu decken)
+ Kundenskonto (im Hundert) (zieht der Kunde sich vom nächsten Preis ab)
+ Provision (im Hundert) (bekommt ggfs. ein Handelsvertreter von uns)
= Zielverkaufspreis (müsste der Kunde zahlen, wenn er auf Rechnung kauft)
+ Kundenrabatt (im Hundert) (handelt der Käufer runter)
= Listenverkaufspreis (auch Nettoverkaufspreis)
+ Umsatzsteuer (geht abzgl. der Vorsteuer ans Finanzamt)
= Bruttoverkaufspreis (schreibt der Händler auf sein Preisschild)

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Handelskalkulation
• BWL – kaufmännisches Rechnen – Die Handelskalkulation
• Die Handelskalkulation – Ein Berechnungs-Schema für optimale Verkaufspreise
• Skontozahlung lohnt sich fast immer
• Warum sich Skonto lohnt: So teuer sind Lieferantenkredite wirklich!
• Rechnen in Hundert, von Hundert, auf Hundert?

Der Beitrag Handelskalkulation, Skonto und Rabatt – Häufige Fragen im Fachgespräch – Anwendungsentwickler-Podcast #148 erschien zuerst auf IT-Berufe-Podcast.

um Ideen für Inhalte von Praktika im IT-Bereich geht es in der einhundertneunundvierzigsten Episode des Anwendungsentwickler-Podcasts.

Inhalt

• Warum sind Praktika für Ausbildungsunternehmen wichtig?
  • Praktikanten werden ggfs. direkt zu Bewerbern auf die Ausbildung.
  • Unter Schülern spricht sich ein gutes Praktikum herum. Das bedeutet kostenfreie Werbung für die Ausbildung.
  • Das Unternehmen bekommt Input von außen zur Attraktivität der Ausbildung und des Unternehmens.
  • Die eigenen Azubis lernen durch das Lehren ihre Ausbildungsinhalte besser.

Tipps für die konkrete Umsetzung

• Die Azubis sollten die komplette Betreuung des Praktikanten übernehmen.
• Das Praktikum kann wie ein echtes Projekt geplant und durchgeführt werden (z.B. im Ticketsystem).
• Dazu zählen auch organisatorische Dinge wie die Datenschutzerklärung, das Einrichten eines Windows-Benutzers, Anfordern einer Bezahlkarte usw.
• Der Praktikant sollte einen realistischen Einblick in den Ablauf der Ausbildung erhalten und keine „heile Welt“ präsentiert bekommen.

Mögliche Praktikumsinhalte

• Der Umfang hängt von der Dauer des Praktikums ab. In zwei Wochen kann man natürlich tiefer in die Programmierung einsteigen als in einer.
• Die Inhalte sollten an die Vorkenntnisse und das Alter des Praktikanten angepasst werden. Ein Schulpraktikum in der 9. Klasse bietet sich z.B. weniger für Hardcore-Programmierung an.
• Die nötigen Praktikumsartefakte (z.B. Praktikumsbericht, -präsentation) sollten in den Praktikumsalltag integriert werden. Fotos können z.B. direkt während der Arbeit gemacht werden.

Allgemeiner Einstieg ins Praktikum

• Begrüßung durch Ausbildungsleiter und betreuende(n) Azubi(s)
• Organisatorische/rechtliche Rahmenbedingungen klären (z.B. Arbeitszeiten, Verhalten bei Krankheit)
• Rundgang durch
  • das Unternehmen (z.B. Kantine, Serverraum, Besprechungsräume, Schulungsraum)
  • die Abteilung (z.B. nächstes WC, Kaffeeküche)
• Vorstellungsrunde mit allen Azubis

Technische Inhalte (Was lernt man in der Ausbildung?)

• Eigenen Arbeitsplatz aufbauen
  • Monitor, Tastatur usw. verkabeln
  • eigenes Passwort ändern
  • ggfs. Software installieren
• PC auseinander-/zusammenbauen
• Eigenen Steckbrief mit HTML/CSS gestalten
• Einstieg in die Programmierung, z.B. mit dem Calliope Mini*
• RaspberryPi* aufsetzen (z.B. RetroPi)
• Tieferer Einstieg in eine Programmiersprache
• Windows-/Linux-Server aufsetzen (VMs)
• Blogartikel/Instagram-Post für die eigene Azubi-Website schreiben
• Praktikumsmappe/-präsentation vorbereiten (insb. Fotos)

Organisatorische Inhalte (Wie läuft der Arbeitsalltag ab?)

• Teilnahme an allen anfallenden Meetings (z.B. Abteilungsbesprechung, Projektplanung, Standup)
• Lernzielkontrollen mit anderen Azubis gemeinsam durchführen
• Pair-Programming mit Azubis durchführen, um echte Projekte kennenzulernen
• Vier-Augen-Gespräch mit Ausbildungsleiter
• Fragebogen zum Beruf und zum Unternehmen ausfüllen

Ausblick (Wie geht es nach dem Praktikum weiter?)

• Weiteres Vorgehen zur Bewerbung klären (z.B. kürzeres Verfahren möglich, da Praktikant schon gut bekannt)
• Vorstellungsgespräch für die Ausbildung simulieren
• Praktikumszeugnis ausstellen und durchsprechen
• Feedback des Praktikanten einholen (z.B. zu den Inhalten, der Betreuung vor Ort, Interesse am Beruf)
• Weiterführende Literatur empfehlen (z.B. IT-Handbuch, Podcast, YouTube-Videos)
• Abschiedsgeschenk überreichen (z.B. USB-Stick mit Programmieraufgaben und -lösungen)

Downloads

• Checkliste zu Beginn des Praktikums in der IT-Abteilung (Praktikumsbetrieb)
  
• Checkliste zum Praktikum in der IT-Abteilung (Praktikant)
  
• Factsheet zur Ausbildung
  
• Feedback zum Praktikum in der IT-Abteilung
  

Links

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

Der Beitrag Praktikumsinhalte in der IT-Abteilung – Anwendungsentwickler-Podcast #149 erschien zuerst auf IT-Berufe-Podcast.

In dieser Sonderepisode des Anwendungsentwickler-Podcasts und gleichzeitig der ersten Episode des IT-Berufe-Podcasts erkläre ich meine Beweggründe für das „Rebranding“.

Inhalt

Der gute alte Anwendungsentwickler-Podcast wird 150! Die nächste Episode ist die einhundertfünfzigste! Grund zum Feiern… und über das Leben nachzudenken. Und durch die zahlreichen Änderungen in der Ausbildung der IT-Berufe, die die Novellierung 2020 mit sich bringt, ist es an der Zeit, den Titel des Podcasts zu verallgemeinern, um die Zielgruppe aller Azubis der IT-Berufe anzusprechen.

Die Novellierung der IT-Berufe hat zur Folge, dass viele Ausbildungsinhalte – insb. in der Berufsschule – für alle 7 IT-Berufe gleich sind. Der neue Rahmenlehrplan sieht vor, dass alle Berufe in den ersten beiden Ausbildungsjahren nahezu identisch beschult werden. Viele Inhalte in meinem Podcast sind daher genauso relevant für die anderen 6 Berufe.

Außerdem bilde ich seit 2019 selbst nicht mehr nur Anwendungsentwickler, sondern auch einen Systemintegrator aus. Und auch er lernt mit meinen Podcast-Episoden, die bereits immer schon allgemeine Ausbildungsinhalte vermittelt haben.

Ich habe sogar extra ein Logo für den Podcast erstellen lassen. Auf fiverr.com ging das innerhalb von 2 Tagen. Ich finde es optisch sehr ansprechend und passend zu meinen Inhalten.

Auch diese Website wird überarbeitet! Ich habe das Design bereits auf ein für Podcasts optimiertes Theme umgestellt und werde auch die Inhalte weiter aufbereiten. Neue Übersichtsseiten, Löschen veralteter Inhalte, Zusammenfassen gleichartiger Artikel. Das alles steht auf der Agenda.

Ich werde natürlich dafür sorgen, dass alte Links erhalten bleiben und weiter funktionieren. Falls dir dennoch Fehler auffallen, freue ich mich über deine Nachricht! Die Website ist inzwischen so groß geworden, dass ich nicht jeder Unterseite selbst kontrollieren kann. Sollten dir also Probleme auffallen, sag mir gerne bescheid:

• Tote Links
• Unendliche Weiterleitungen
• Darstellungsprobleme
• Falsche Suchergebnisse
• Externe Links mit alten Domains

Ich freue mich auf die Möglichkeiten, die die neue Ausrichtung mit sich bringt, und hoffe, dass du meinem Podcast trotz neuem Namen treu bleibst!

Viele Grüße! Stefan

Links

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

Der Beitrag Rebranding des Anwendungsentwickler-Podcasts – IT-Berufe-Podcast #0 erschien zuerst auf IT-Berufe-Podcast.

Um die Neuerungen, aber auch weitere wichtige Festlegungen des Berufsbildungsgesetzes (BBiG) geht es in der einhundereinundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Dies ist meine Auswahl an „interessanten“ Auszügen aus dem (neuen) BBiG. Neben den Änderungen zum 01.01.2020 habe ich auch einige „alte“ Paragraphen aufgeführt, die einige wichtige Sachverhalte rund um die Ausbildung klären, von denen jeder Ausbilder und Azubi mal gehört haben sollte.

§7a: Teilzeitausbildung

Jeder Azubi hat nun das Recht, seine Ausbildung in Teilzeit zu absolvieren. Dabei kann die Arbeitszeit um max. 50% reduziert werden. Die reduzierte Arbeitszeit muss an die Dauer der Ausbildung angehängt werden. Beispiel: 50% Reduktion (z.B. 19 statt 38 Stunden pro Woche), dafür 50% Verlängerung (4,5 statt 3 Jahre). Ob und wie die Berufsschule das Ganze unterstützt ist (noch) nicht festgelegt.

§14 Bereitstellung von Fachliteratur

Das Ausbildungsunternehmen muss dem Azubi nun auch Fachliteratur bereitstellen (z.B. leihen oder kaufen). Bislang galt das nur für Werkzeuge usw., was für unsere IT-Berufe aber so gut wie nie nötig war.

In diesem Paragraphen steht übrigens auch, dass das Berichtsheft am Arbeitsplatz zu führen ist (und nicht etwa in der Freizeit).

§15 Freistellung für die Berufsschule

Jeder Azubi (egal ob minder- oder volljährig) bekommt nun an einem Berufsschultag mit mehr als 5 Unterrichtsstunden zu je 45 Minuten seine gesamte tägliche Arbeitszeit angerechnet (z.B. 8 Stunden bei einer 40-Stunden-Woche) und muss an diesem Tag nicht mehr ins Unternehmen. Bei einer Blockwoche mit mind. 25 Unterrichtsstunden an mind. 5 Tagen wird die gesamte wöchentliche Arbeitszeit angerechnet (z.B. 40 Stunden).

Azubis werden am Arbeitstag vor der schriftlichen Prüfung (in Zukunft einmal nach 18 Monaten zum ersten Teil der gestreckten Abschlussprüfung und einmal nach 3 Jahren zum zweiten) freigestellt.

§17 Mindestausbildungsvergütung

Es gibt nun einen „Mindestlohn“ für Azubis, der sich in den kommenden Jahren schrittweise erhöht. Im Jahr 2020 liegt er bei 515 EUR pro Monat. Es gibt allerdings einige Ausnahmen von dieser Regelung, insb. für Betriebe, die keinem Tarifvertrag unterliegen.

§21 Ausbildungsende mit Bekanntgabe des Ergebnisses

Die Ausbildung endet bereits vor dem im Ausbildungsvertrag vereinbarten Ende mit der Mitteilung des Prüfungsergebnisses durch den Prüfungsausschuss an den Azubi. Damit sind nicht die Noten gemeint (die oft nicht herausgegeben werden dürfen), sondern das „Kreuzchen“ bei „bestanden“.

§24 Unbefristeter Vertrag durch Weiterbeschäftigung

Sollte der Azubi am Tag nach der Prüfung (sofern er bestanden hat) ohne einen Arbeitsvertrag weiter in deinem Unternehmen beschäftigt werden, gilt damit automatisch ein unbefristeter Arbeitsvertrag als begründet.

§27 angemessenes Verhältnis von Azubis zu Fachkräften

Betriebe dürfen nicht einfach so viele Azubis beschäftigen wie möglich, sondern müssen für ein angemessenes Verhältnis zur Anzahl der Fachkräfte sorgen. Das Gesetz nennt keine Zahlen, aber an anderer Stelle ist von einem Verhältnis von ungefähr 3 Fachkräften je 1 Azubi zu lesen.

§30 Fachliche Eignung der Ausbilder

Ausbilden dürfen Personen, die den gleichen (oder einen ähnlichen) Berufsabschluss erworben haben (also die IHK-Prüfung abgelegt haben). Außerdem dürfen auch Hochschulabsolventen eines vergleichbaren Faches ausbilden.

§37 Wiederholen der Prüfung und Berufsschulnote auf dem IHK-Zeugnis

Die Abschlussprüfung darf bei Nichtbestehen zweimal wiederholt werden.

Wenn der Azubi die Abschlussnote der Berufsschule mit auf das IHK-Zeugnis gedruckt haben möchte, kann er dafür einfach eine Kopie seines Berufsschulzeugnisses einreichen.

§40 Mind. 3 Prüfer im Ausschuss

Der Prüfungsausschuss muss aus mind. 3 Personen bestehen. Der Ausschuss muss paritätisch aus Lehrern, Arbeitnehmer- und Arbeitgebervertretern besetzt sein.

Ab 2020 sind Prüfer für ihre ehrenamtliche Tätigkeit vom Arbeitgeber freizustellen.

§42 Prüferdelegationen

Statt des in §40 beschriebenen Ausschusses aus mind. 3 Personen, können von der IHK auch sog. Prüferdelegationen bestimmt werden, die mit weniger Teilnehmern prüfen dürfen.

Prüfungsartefakte wie die Projektdokumentation, die nicht die Anwesenheit des Prüflings für die Bewertung erfordern (wie z.B. das Fachgespräch), können auch von nur 2 Prüfern bewertet werden.

§43 Zulassung zur Prüfung nur mit Zwischenprüfung und Berichtsheft

Azubis dürfen die Abschlussprüfung nur ablegen, wenn sie an der Zwischenprüfung teilgenommen haben (bestehen muss man nicht) und ihren Ausbildungsnachweis (das geliebte Berichtsheft) ordnungsgemäß geführt haben.

§45 Zulassung zur Prüfung durch 1,5x Ausbildungszeit im Beruf

Quereinsteiger können zur Prüfung zugelassen werden, wenn sie das 1,5-fache der Ausbildungszeit (also 1,5 * 3 = 4,5 Jahre) praktisch im Beruf gearbeitet haben.

§48 Zwischenprüfung entfällt bei gestreckter Abschlussprüfung

Ab 2020 werden die Prüflinge in den IT-Berufen auch eine gestreckte Abschlussprüfung absolvieren müssen. In diesem Fall entfällt die Zwischenprüfung. Sie wird ersetzt durch den ersten Teil der Abschlussprüfung.

§53a Abschlussbezeichnungen

Ab 2020 werden die verschiedenen Weiterbildungen nach der Ausbildung (z.B. Meister, Fachwirt, Operative Professional) den akademischen Abschlüssen Bachelor und Master gleichgestellt. Abhängig vom zeitlichen Umfang der Weiterbildungen darf man sich dann z.B. „Bachelor Professional“ nennen.

§101 Bußgelder für ausbildungsfremde Tätigkeiten

Dieser Paragraph listet einige Ordnungswiedrigkeiten auf, die teils mit Geldstrafen bis zu 5.000 EUR belegt werden können. Insb. die Beschäftigung von Azubis mit ausbildungsfremden Tätigkeiten ist hier erwähnenswert.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Das neue Berufsbildungsgesetz (BBiG)
• Berufsbildungsgesetz novelliert: Die wichtigsten Neuerungen im Überblick
• Datenbank Tarifliche Ausbildungsvergütungen
• Voraussetzungen für die betriebliche Ausbildung / 2.5 Das Verhältnis der Zahl der Auszubildenden zur Zahl der Fachkräfte

Der Beitrag Das (neue) Berufsbildungsgesetz (BBiG) – IT-Berufe-Podcast #150 erschien zuerst auf IT-Berufe-Podcast.

Um die langersehnte Neuordnung der IT-Berufe zum 01.08.2020 geht es in der einhunderteinundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

1. Zusammenfassung der Änderungen
2. Vergleich der Ausbildungsverordnungen
3. Prüfungsinhalte Teil 1
4. Neuer Rahmenplan vs. alter Rahmenplan
5. Alter Rahmenplan vs. neuer Rahmenplan
6. Downloads
7. Links

Zusammenfassung der Änderungen für Fachinformatiker

• Einführung von zwei neuen Fachrichtungen: Daten- und Prozessanalyse (FIDP) und Digitale Vernetzung (FIDV)
  • FIDP ist quasi der „KIler“ unter den Fachinformatikern, aber auch in Richtung (SAP-)Beratung unterwegs
  • FIDV ist im Bereich Industrie 4.0 zuhause und hat einen großen Bezug zu den Systemelektronikern
• Einführung einer gestreckten Abschlussprüfung
  • Teil 1: Einrichten eines IT-gestützten Arbeitsplatzes
  • für alle IT-Berufe identisch
  • nach 18 Monaten
  • ersetzt die Zwischenprüfung und ist relevant für die Abschlussnote
  • 90min schriftliche Prüfung
• Neue Gewichtung der Prüfungsteile für die Abschlussnote
  • Teil 1: 20%
  • Projektarbeit: 50% (davon jeweils 50% für Dokumentation und Präsentation/Fachgespräch)
  • zwei berufsspezifische schriftliche Prüfungen (früher GA1 und GA2): jeweils 10%
  • Wirtschafts- und Sozialkunde: 10%
• Mehr Zeit für die Projektarbeiten: 80h für FIAE, 40h für alle anderen

(nach oben)

Vergleich der Ausbildungsverordnungen

(nach oben)

Prüfungsinhalte Teil 1

• 1a: Grundsätze und Methoden des Projektmanagements anwenden
• 1b: Auftragsunterlagen und Durchführbarkeit des Auftrags prüfen, insbesondere in Hinblick auf rechtliche, wirtschaftliche und terminliche Vorgaben, und den Auftrag mit den betrieblichen Prozessen und Möglichkeiten abstimmen
• 1c: Zeitplan und Reihenfolge der Arbeitsschritte für den eigenen Arbeitsbereich festlegen
• 1d: Termine planen und abstimmen sowie Terminüberwachung durchführen
• 1e: Probleme analysieren und als Aufgabe definieren sowie Lösungsalternativen entwickeln und beurteilen
• 1f: Arbeits- und Organisationsmittel wirtschaftlich und ökologisch unter Berücksichtigung der vorhandenen Ressourcen und der Budgetvorgaben einsetzen
• 1g: Aufgaben im Team sowie mit internen und externen Kunden und Kundinnen planen und abstimmen
• 1h: betriebswirtschaftlich relevante Daten erheben und bewerten und dabei Geschäfts- und Leistungsprozesse berücksichtigen
• 1i: eigene Vorgehensweise sowie die Aufgabendurchführung im Team reflektieren und bei der Verbesserung der Arbeitsprozesse mitwirken
• 2a: im Rahmen der Marktbeobachtung Preise, Leistungen und Konditionen von Wettbewerbern vergleichen
• 2b: Bedarfe von Kunden und Kundinnen feststellen sowie Zielgruppen unterscheiden
• 2c: Kunden und Kundinnen unter Beachtung von Kommunikationsregeln informieren sowie Sachverhalte präsentieren und dabei deutsche und englische Fachbegriffe anwenden
• 2d: Maßnahmen für Marketing und Vertrieb unterstützen
• 2e: Informationsquellen auch in englischer Sprache aufgabenbezogen auswerten und für die Kundeninformation nutzen
• 3a: marktgängige IT-Systeme für unterschiedliche Einsatzbereiche hinsichtlich Leistungsfähigkeit, Wirtschaftlichkeit und Barrierefreiheit beurteilen
• 3b: Angebote zu IT-Komponenten, IT-Produkten und IT-Dienstleistungen einholen und bewerten sowie Spezifikationen und Konditionen vergleichen
• 4a: IT-Systeme zur Bearbeitung betrieblicher Fachaufgaben analysieren sowie unter Beachtung insbesondere von Lizenzmodellen, Urheberrechten und Barrierefreiheit konzeptionieren, konfigurieren, testen und dokumentieren
• 4b: Programmiersprachen, insbesondere prozedurale und objektorientierte Programmiersprachen, unterscheiden
• 5a: betriebliche Qualitätssicherungssysteme im eigenen Arbeitsbereich anwenden und Qualitätssicherungsmaßnahmen projektbegleitend durchführen und dokumentieren
• 6a: betriebliche Vorgaben und rechtliche Regelungen zur IT-Sicherheit und zum Datenschutz einhalten
• 6b: Sicherheitsanforderungen von IT-Systemen analysieren und Maßnahmen zur IT-Sicherheit ableiten, abstimmen, umsetzen und evaluieren
• 7a: Leistungen nach betrieblichen und vertraglichen Vorgaben dokumentieren
• 7b: Leistungserbringung unter Berücksichtigung der organisatorischen und terminlichen Vorgaben mit Kunden und Kundinnen abstimmen und kontrollieren
• 7c: Veränderungsprozesse begleiten und unterstützen
• 7d: Kunden und Kundinnen in die Nutzung von Produkten und Dienstleistungen einweisen
• 7e: Leistungen und Dokumentationen an Kunden und Kundinnen übergeben sowie Abnahmeprotokolle anfertigen
• 7f: Kosten für erbrachte Leistungen erfassen sowie im Zeitvergleich und im Soll-Ist-Vergleich bewerten

(nach oben)

Inhalte des neuen Rahmenplans im alten Rahmenplan (was ist neu?)

(nach oben)

Inhalte des alten Rahmenplans im neuen Rahmenplan (was ist weggefallen oder hat sich geändert?)

(nach oben)

Downloads

• Vergleich des alten und neuen Ausbildungsrahmenplans für Fachinformatiker als Excel-Datei (enthält die obigen Tabellen)
• Neuer Ausbildungsrahmenplan für Fachinformatiker ab 01.08.2020 als Excel-Datei (enthält alle zu vermittelnden Kenntnisse, Fähigkeiten und Fertigkeiten aufgeteilt nach berufsprofilgebend, integrativ und Fachrichtung)

(nach oben)

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Verordnung über die Berufsausbildung zum Fachinformatiker und zur Fachinformatikerin (Fachinformatikerausbildungsverordnung – FIAusbV) im Bundesgesetzblatt
• Verordnung über die Berufsausbildungzum Kaufmann für IT-System-Management und zur Kauffrau für IT-System-Management (IT-System-Management-Kaufleute-Ausbildungsverordnung – ITSManKflAusbV) im Bundesgesetzblatt
• Verordnung über die Berufsausbildung zum Kaufmann für Digitalisierungsmanagement und zur Kauffrau für Digitalisierungsmanagement(Digitalisierungsmanagement-Kaufleute-Ausbildungsverordnung – DigiManKflAusbV) im Bundesgesetzblatt
• Verordnung über die Berufsausbildung zum IT-System-Elektroniker und zur IT-System-Elektronikerin (IT-System-Elektroniker-Ausbildungsverordnung – ITSEAusbV) im Bundesgesetzblatt

Der Beitrag Neuordnung der IT-Berufe zum 01.08.2020 – IT-Berufe-Podcast #151 erschien zuerst auf IT-Berufe-Podcast.

Viele konkrete Bewerbungstipps und Infos über den Bewerbungsprozess in Unternehmen von Personalvermittlerin Vanessa Stammnitz gibt es in der einhundertzweiundfünfzigsten Episode des IT-Berufe-Podcasts.

Allgemeines zur Person

• Wie ist dein Name und wo arbeitest du?
  • Vanessa Stammnitz, seit 2017 Inhaberin von Stammnitz Personal, einer Personalberatung mit Schwerpunkt SAP.
  • Ich komme ursprünglich aus Leipzig, lebe und arbeite aber in Esslingen.
  • Wir vermitteln insb. SAP-Berater, sind aber auch im Bereich Industrie 4.0 unterwegs. Die beiden Bereiche wachsen aktuell zusammen, da Künstliche Intelligenz, Robotik und autonome Bereiche der Produktion auch in SAP Einzug halten bzw. von dort gesteuert oder überwacht werden.
• An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?
  • Ich bin in der Personalvermittlung tätig, die häufig in Form von kleinen Projekten abläuft. Ein Kunde erteilt mir z.B. einen Suchauftrag für einen SAP-Entwickler und ich lege los, z.B. mit einer Internet-Recherche.
  • Meine Kunden sind häufig Startups, z.B. aus dem Bereich Industrie 4.0, die oft (noch) keine eigene Human-Resources- oder Personalabteilung haben, und teils zum ersten Mal außerhalb des eigenen Freundeskreises Personal suchen.
  • Ich bin Ansprechpartner für viele Aufgaben im Bereich Personal, z.B. auch Coaching, Teamaufbau, Mitarbeiter führen und halten, alte Hierarchien aufbrechen.
  • Die Arbeitswelt ändert sich aktuell stark. Stichwörter sind Arbeit 4.0, Homeoffice, Agilität oder New Work. Dafür braucht man neue Prozesse oder Strategien. Unternehmen müssen mitarbeiterfreundlicher werden, denn wir haben aktuell einen Bewerbermarkt!
  • Es gibt viel zu wenige Bewerber aktuell. Meine Kunden suchen teilweise 1-2 Jahre selbst, bevor sie mich ansprechen. Viele haben schon ihre Anforderungen an die Bewerber herruntergeschraubt und trotzdem niemanden gefunden.
  • Mitarbeiter müssen Spaß an der Arbeit haben! Aktuelle Hypes sind z.B. Großraumbüros mit viel Glas und ohne feste Arbeitsplätze. Das führte jedoch dazu, dass viele Entwickler das gar nicht so gut fanden. Wer möchte schon jeden Tag um seinen „Lieblingsplatz“ mit den Kollegen kämpfen? Wenn man dank Homeoffice nur 2 Mal im Monat im Büro ist, geht das vielleicht, aber für die tägliche Arbeit ist das Mist.
• Wie bist du zur Personalvermittlung gekommen?
  • Ich habe klassisch BWL studiert. Mein duales Studium habe ich im Handel absolviert in einem eher konservativen Unternehmen. Danach habe ich bewusst eine 180-Grad-Wendung gemacht und auf einer Jobmesse eine Personalberatung als neuen Arbeitgeber entdeckt. Danach habe ich mich dann in diesem Bereich selbstständig gemacht.
• Welche Ausbildung bzw. welches Studium hast du absolviert?
  • Leider kann man „Personal“ nicht direkt studieren und es gibt auch keine Ausbildung. Viele Personalvermittler sind daher ITler oder – wie ich – BWLer.
  • Meine Mitarbeiterin Jannika ist Studentin mit Schwerpunkt Personalmanagement. Einige Master-Studiengänge drehen sich um Personal. Das Thema hat auch viel mit Psychologie zu tun und natürlich auch mit rechtlichen Inhalten.

Personaldienstleistungen

Recruiting-Prozess

• Wie sieht die tägliche Arbeit einer Personalberaterin aus?
  • Ca. 70% der Arbeit laufen telefonisch ab, 30% per Mail oder im persönlichen Gespräch.
  • Ich muss viele Details und Fragen mit potentiellen Kandidaten abklären.
  • Die technische Suche läuft häufig über Xing bzw. LinkedIn, aber vermehrt auch einfach per Google.
  • Ich finde viele Lebensläufe über Google, komplett mit Namen, Bild usw. völlig frei zugänglich.
  • Da sind immer häufiger auch Bilder oder Videos online, die für den Bewerber nicht so toll aussehen.
  • Beispiel: Ein Azubi suchte einen neuen Betrieb. Bei einer Google-Suche nach seinem Namen wurde direkt ein Bild von ihm im Anzug, aber mit einer Feuerwaffe in der Hand angezeigt. Das finde nicht nur ich schnell, sondern auch ein potentieller Arbeitgeber.
  • Ich coache auch Bewerber, die sich – gerade in der IT – falsch oder unglücklich darstellen. Sie stellen ihr Licht häufig unter den Scheffel. Da pushe ich ein bisschen, damit sie mir Selbstvertrauen zeigen.
• Muss man heutzutage (als ITler) online auffindbar sein?
  • Grundsätzlich haben einfach viele ITler heute eine Online-Präsenz.
  • Und Bewerber werden über Google gesucht! Dessen muss man sich einfach bewusst sein.
  • Seine (technischen) Projekte zu zeigen ist sicherlich gut für Bewerber. Aber auch die privaten Hobbys – z.B. eine Fotografie-Seite – sind potentiell interessant, da es bei Stellenbesetzungen oftmals um den Menschen geht und nicht um die Technik.
  • Andersherum ist es vielleicht für einen Bewerber im Bereich IT-Security gerade gut, wenn man ihn nicht online findet! Da könnte man direkt im Bewerbungsgespräch fragen, wie er das hinbekommen hat.
  • Insgesamt sollte der Online-Auftritt einfach zum anvisierten Job passen. Ein Webentwickler sollte heute einfach online sein!

Sicht der Bewerber

• Wie läuft der gesamte Prozess bis zur Einstellung ab?
  • Bewerber bewerben sich direkt auf Stellenausschreibungen, für die ich die Ansprechpartnerin bin oder bitten mich um Hilfe bei der Stellensuche.
  • Ich frage dann zuerst, warum er wechseln möchte. Liegt es z.B. am Standort, dem Geld usw.?
  • Dann frage ich, welches Unternehmen passen könnte oder welcher Fachbereich.
  • Gerade direkt nach Ausbildung ist das wichtig: Welcher Bereich passt zum Bewerber? Soll es vielleicht doch noch ein Studium sein? Ist vielleicht ein Sabbatical geplant?
  • Wichtig ist auch die Unterscheidung zwischen Großkonzern und Mittelstand oder Kleinunternehmen.
  • Das kostet zwar zunächst Zeit, filtert aber viele unpassende Stellen direkt heraus und lohnt sich daher später.
  • Weitere Fragen sind z.B. Präferenzen zur Teamarbeit vs. Homeoffice, Bedürfnisse von Bewerbern mit Kindern, Interesse an Teilzeit usw.
  • Nach diesem Vorgespräch suche ich dann eine konkrete Stellenausschreibung und stelle sie dem Bewerber vor, inkl. Informationen zum zukünftigen Chef, den Projekten, ggfs. nötigen Englischkenntnissen usw.
  • Viele Bewerber sind gerade bei der ersten Bewerbung überwältigt von dem ganzen Drumherum.
• Wer übernimmt die Kosten für das Verfahren?
  • Für die Bewerber ist eine Personalberatung immer kostenfrei. Die Unternehmen bezahlen die Vermittlungskosten.
• Welche Vorteile bietet die Zusammenarbeit mit einer Personalberaterin den Bewerbern?
  • Personalberater sind neutrale Partner der Bewerber. Ihnen darf man auch „dumme“ Fragen stellen. Und sie beruhigen die Kandidaten z.B. vor dem ersten Interview durch ein Bewerbungstraining.
  • Wann fragt man z.B. am besten nach dem Gehalt? Das kann ggfs. schon vorab geklärt werden. Meist ist zumindest eine Gehaltsspanne bekannt.
  • Personalberater suchen auch direkt gut passende Stellen für die Bewerber heraus.
  • „Traumarbeitgeber“ kann man auch nennen und manchmal funktioniert das sogar. Viele Bewerber wissen aber gar nicht genau, warum sie z.B. zu Microsoft wollen.
  • Startups tun sich häufig schwer, gute Bewerber zu finden, weil die Kandidaten eher zu etablierten Unternehmen wollen.
  • Dabei sind Startups durchaus interessante Arbeitgeber. Ich betreue z.B. seit 2014 einen Kunden mit 4 IT-Mitarbeitern, der SAP eingeführt hat. Dort habe ich von Beginn an das Team mit aufgebaut. Der Chef war sehr nett, aber das wusste niemand, da das Startup sich noch keinen Namen gemacht hatte.
  • Gerade Junioren lassen sich häufig von Geld blenden. Eine Forderung nach 65.000 EUR zum Einstieg ist da keine Seltenheit. Dabei sind ein doofer Chef und langweilige Aufgaben viel schlimmer für die Zufriedenheit als (scheinbar) wenig Geld.
• Worauf sollte man bei den Bewerbungsunterlagen besonders achten?
  • Viele meiner Kunden legen nicht viel Wert auf fachliche/technische Inhalte. Noten sind auch gar nicht so wichtig, sofern man „Ausrutscher“ gut begründen kann. Das persönliche Gespräch ist deutlich wichtiger.
  • Klassische Pflichtinhalte einer Bewerbung sind sicherlich Lebenslauf und Zeugnisse.
  • Heutzutage ist eine Projektliste auch wichtiger als ein klassischer Lebenslauf. Die Unternehmen wollen wissen, was man wirklich praktisch angewendet hat.
  • Außerdem sollte man zeigen, dass noch mehr hinter dem Bewerber steckt als die üblichen Buzzwords.
  • Sich per Xing oder LinkedIn zu bewerben geht inzwischen auch schon häufig.
• Sind Arbeits- oder Schulzeugnisse wichtiger?
  • Arbeitszeugnisse sind extrem wichtig! Gerade in Deutschland werden sie sehr genau gelesen. Dabei ist die Note 1 oder 2 nicht so wichtig, sondern mehr die Vollständigkeit.
  • Ein „Alarm“ für potentielle Arbeitgeber ist, wenn zwar alle Schulzeugnisse vorliegen, aber kein Arbeitszeugnis! Das wirkt sofort seltsam.
  • Schlechte Noten, z.B. in Mathe, sind gar nicht so schlimm. Für einige Inhalte kann es z.B. einfach zu früh gewesen sein in der Schule. Ich selbst habe Mathe auch erst im Studium so richtig verstanden.
  • Die Abschlussnote der Ausbildung ist fast egal, sofern man die Ausbildung bestanden hat.
• Ist ein Anschreiben heute noch zeitgemäß?
  • Nein, ein Anschreiben wird heute oftmals nicht mehr benötigt. Die begleitende E-Mail ist meist schon Anschreiben genug.
• Wie kann man als Bewerber seine Kenntnisse in bestimmten Technologien demonstrieren?
  • Durch die angehängte Projektliste und/oder Referenzen früherer Arbeitgeber.
• Wie wichtig sind Zertifizierungen (z.B. MCSE)?
  • Meine persönliche Meinung ist, dass Zertifikate niemals die praktische Erfahrung ersetzen können.
  • Beispiel: SAP: Das Zertifikat reicht nicht, um wirklich praktisch arbeiten zu können. Es kostet viel Geld und reicht trotzdem nicht zum Einstieg in den Beruf. Ein Praktikum im Unternehmen ist da schon viel sinnvoller.
• Sollten sich Bewerber auf Stellen bewerben, für die sie nur einen kleinen Teil der Anforderungen erfüllen?
  • Erstmal werden ca. 85% der Stellenanzeigen gar nicht von der IT-Abteilung geschrieben, sondern von der Personalabteilung. Es ist schon sehr spannend, was da manchmal so drin steht.
  • Der perfekte Kandidat ist da so gut wie nie möglich.
  • Also ein klares Ja! Man sollte sich auf jeden Fall trotzdem bewerben, auch wenn man nicht alle geforderten Skills mitbringt.
  • Wenn man allerdings komplett fachfremd ist, sollte man vielleicht einfach vorher im Unternehmen anrufen und nachfragen. Aber 1-2 fehlende Anforderungen kann man einfach in die Bewerbung mit aufnehmen und z.B. darauf hinweisen, dass man sich einarbeiten möchte und kann.
  • Die Erwartungen der Kunden sind teils völlig unrealistisch, z.B. 5 Jahre Berufserfahrung, Chinesisch als Zweitsprache, 100% Reisebereitschaft, aber nur 60.000 EUR Jahresgehalt.
• Wann ist der beste Zeitpunkt, um sich als Azubi auf einen Job nach der Ausbildung zu bewerben?
  • Ein halbes Jahr vor dem Start in den Job ist super, wenn das geht, damit man genug Puffer hat. Der Recruiting-Prozess dauert oft 2-3 Monate.
  • Da dann natürlich noch kein Prüfungszeugnis vorliegt, sollte man nach einem Zwischenzeugnis fragen, damit man sich damit bewerben kann.
  • Unternehmen, die ihre Azubis nach der Ausbildung nicht übernehmen, müssen sie im Bewerbungsprozess unterstützen.
• Wie lange brauchen die Unternehmen für den Recruiting-Prozess?
  • Ein Tag war der kürzeste Prozess, den ich mitbekommen habe. Es war der Nachbar des Teamleiters! Die beiden haben abends am Gartenzaun geschwätzt und er hatte den Job.
  • In der Regel kommt nach 1-2 Wochen eine erste Rückmeldung, weil oft viele Mitarbeiter auf die Bewerbung schauen müssen und sie z.B. nicht vor Ort sind.
  • Bis zum Abschluss mit Unterschrift, Kündigung beim alten Arbeitgeber usw. vergehen dann üblicherweise 2-3 Monate.
  • Schnelle Antworten sind dabei ein klarer Wettbewerbsvorteil für suchende Unternehmen. Oft wird das 2. Vorstellungsgespräch in einem kleinen Unternehmen schon geführt, bevor der Großkonzern sich überhaupt zurückgemeldet hat.
  • Ich habe mich z.B. selbst auf ein duales Studium beworben und erst im März eine Rückmeldung für das Studium mit Beginn zum Oktober des Vorjahres (!) bekommen.
• Was macht man als Bewerber, wenn man mehrere Jobangebote erhält?
  • Wenn die Gespräche zeitlich auseinander liegen, sollte man der Fairness halber mit offenen Karten spielen.
  • Bei mehreren ähnlichen Angeboten sollte man sie genau vergleichen. Eine Pro-/Contra-Liste hat schon vielen meiner Kunden geholfen. Bei einem hat letztlich die bessere Kantine den Ausschlag gegeben.
  • Solch eine Entscheidung ist immer eine Belastung für den Bewerber. Das Bauchgefühl ist hierbei wichtig. Das sollte man nicht unterschätzen.
  • Wenn man sich unsicher bzgl. einer Stelle ist, wird es rückblickend später fast immer eine schlechte Entscheidung gewesen sein.

Sicht der Unternehmen

• Was macht man, wenn es mehrere gute Kandidaten gibt?
  • Die Unternehmen erzählen es der Vermittlerin, die dann Fingerspitzengefühl zeigen muss. Alternativ sollte man auch als Unternehmen offen und ehrlich sein und niemanden hinhalten.
• Warum sollten Unternehmen die wichtige Aufgabe des Recruitings aus der Hand geben?
  • Oft sind Ressourcen das große Problem. Recruiting ist sehr zeitintensiv und Personaler haben natürlich auch noch andere Aufgaben.
  • Außerdem haben Recruiter ggfs. deutlich mehr Erfahrung im konkreten Bereich, für den gesucht wird (z.B. IT vs. Buchhaltung).
  • Profis können außerdem auf Augenhöhe mit IT-Bewerbern sprechen.
• Worauf legen die Unternehmen bei der Besetzung einer neuen Stelle besonders Wert?
  • Viele hören tatsächlich auf ihr Bauchgefühl. Teamfähigkeit ist aber fast allen wichtig.
  • Ansonsten sind die Anforderungen sehr unterschiedlich.
  • Einige Unternehmen wollen z.B. viel Fachlichkeit, aber der Charakter der Bewerber ist nie (!) egal.
  • Manchmal wird auch bewusst ein bestimmter Charakter gesucht. Beispiel: Extrovertierte Person für ein bestehendes Team aus Introvertierten.
  • Viele Kunden haben auch nur (!) noch persönliche Anforderungen. Ein Kunde suchte z.B. einen „Junior-Nerd“, der sich selbst einarbeiten kann, mit YouTube Dinge ausprobiert, selbstständig Probleme lösen kann und das „Feuer in den Augen“ mitbringt.
• Haben Studenten bessere Chancen auf dem Bewerbermarkt als ausgelernte Azubis?
  • Nein, Azubis sind meist genauso gut geeignet für viele Stelle. Azubis sind teilweise sogar besser. Klassische Wirtschaftsinformatiker haben z.B. oft nur die Theorie gelernt, aber keine Praxis. Da muss der Bachelor leider gegenüber dem Fachinformatiker einpacken.
  • Das Vorurteil, dass Studenten nötig sind, ist überholt.
  • Ich kann nur allen ehemaligen Azubis raten, sich auf Stellen zu bewerben, selbst wenn explizit nach einem Studium gefragt wird.
• Wie anerkannt sind Umschulungen im Vergleich zur Ausbildung?
  • Das kommt auf die Umschulung an. Wie hat sich die Person vorbereitet? Wurden Praktika gemacht? Ist es eine langjährige Umschulung?
  • Grundsätzlich ist eine Umschulung völlig ok. Viele Unternehmen sind auch für ältere Bewerber offen.
  • Beispiel: Ich selbst habe einen 62 Jahre alten Bewerber vermittelt. Seine Stelle wurde abgebaut und er hatte noch 3 Jahre bis zur Rente, die er nutzen wollte. Mein Kunde suchte genau für 3 Jahre einen Mitarbeiter und hat gleichzeitig einen Junior eingestellt, dem der erfahrene Mitarbeiter dann sein Wissen vermittelt hat.
• Welche IT-Kenntnisse sind aktuell bei den Unternehmen am gefragtesten?
  • Es wird so gut wie alles nachgefragt, aber viel wichtiger sind persönliche Kompetenzen wie das Einbinden der Fachbereiche und die Kommunikation.
  • Das klassisches Bild des Nerds hat ausgedient!
• Hat sich der Arbeitsmarkt in der IT-Branche in den letzten Jahren verändert?
  • Ja, es ist definitiv ein Bewerbermarkt geworden!

Abschluss

• Haben wir noch Themen vergessen, die wir unbedingt besprechen sollten?
  • Gerade bei der ersten Jobsuche sollte man motiviert rangehen.
  • Eine Personalberatung sollte man auch mit Bauchgefühl aussuchen. Wissen die, wovon sie reden?
  • Für mich persönlich ist es schön zu sehen, wie sich „meine“ Bewerber entwickelt haben.
• Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?
  • Auf meiner Website
  • Hier gibt es auch meinen Blog, u.a. mit typischen Interview-Fragen.
  • Bei Xing
  • Bei LinkedIn

Links

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

Der Beitrag Bewerbungstipps und Recruiting-Prozess mit Personalvermittlerin Vanessa Stammnitz – IT-Berufe-Podcast #152 erschien zuerst auf IT-Berufe-Podcast.

Über die Agile Ausbildung bei DATEV in Nürnberg spreche ich mit Uwe Ritthammer in der einhundertdreiundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Allgemeines zur Person

• Wie ist dein Name und wo arbeitest du?
  • Ich bin Uwe Ritthammer und ich komme aus dem schönen Nürnberg in Franken (nicht Bayern! ;-))
  • Ich arbeite bei DATEV. Wir entwickeln u.a. Software für Steuerberater. Wir haben ca. 8.000 Mitarbeiter, darunter 200 Azubis und Duale Studierende.
  • In meiner Abteilung sind wir mit insg. 8 Personen für die Ausbildung zuständig. Wir übernehmen das volle Programm inkl. Marketing, Recruiting, Betreuung und Übernahme.
  • Der IT-Bereich überwiegt bei uns. Ca. 65% der Azubis arbeiten in der IT, der Rest ist kaufmännisch unterwegs, aber es gibt u.a. auch Dialogmarketing.
• An welchen Projekten arbeitest du zur Zeit in deinem Tagesjob?
  • Ich arbeite operativ mit den Azubis. Ich bin seit 2018 Ausbildungleiter und habe seitdem leider etwas weniger Zeit für aktive Zusammenarbeit.
• Wie bist du zur Informatik bzw. Softwareentwicklung gekommen?
  • Ich habe schon als Kind gerne Computerspiele gespielt. Ich bin über Atari 2600, C64 und Amiga 500 zur Programmiersprache BASIC gekommen. Außerdem habe ich Assembler und C programmiert.
  • Dann habe ich eine Ausbildung zum Datenverarbeitungskaufmann gemacht und nachher noch studiert.
  • Zur Ausbildung bin ich über meine Berufspraxis gekommen. Dort habe ich lange Zeit IT-Schulungen durchgeführt.
• Welche Ausbildung bzw. welches Studium hast du im Bereich der Informatik absolviert?
  • Ich habe klassisch Informatik studiert mit Schwerpunkt Wirtschaft.
• Mit welchen Programmiersprachen arbeitest du im Alltag?
  • Wir entwickeln klassischerweise Windows-Anwendungen, daher hauptsächlich C#. Aber das wird weniger und wandert ins Web. Dort bin ich mit Java unterwegs. Auch die üblichen Frameworks wie Bootstrap zusammen mit JavaScript setze ich ein. Ich habe aber auch mal COBOL auf dem guten alten Mainframe entwickelt.
• Was ist deine Lieblingsprogrammiersprache und warum?
  • C! Privat nutze ich gerne Linux und hacken geht mit C dort sehr gut. Dafür nehme ich sogar die möglichen Speicherlecks in Kauf.

Agile Ausbildung

• Wie ist die Idee zur agilen Ausbildung entstanden?
  • Wir haben das agile Manifest auf die Ausbildung übertragen. Dessen Werte fanden wir sehr passend: Individuen über Prozesse, funktionierende Software über Dokumentation, Zusammenarbeit über Vertragsverhandlungen, Reaktion auf Veränderungen über Verfolgen eines Plans.
  • Der Ausbildungsrahmenplan der IHK steht dem nur scheinbar genau gegenüber. Die Berufsbilder sind seit 1997 recht technologieunabhängig formuliert. Der Rahmen wurde zwar vorgegeben, kann aber gedehnt werden. Auch nach 20 Jahren sind die Inhalte noch aktuell.
  • Dieser Rahmen ist daher gar nicht so starr wie er scheint. Wir können uns frei bewegen innerhalb der Grenzen.
  • Es gibt dafür sogar einen eigenen Paragraphen: man kann vom Rahmen abweichen, wenn dies notwendig oder sinnvoll ist. Das Berufsbild gibt nur die Mindestanforderungen vor.
• Wie funktioniert die agile Ausbildung genau?
  • Das ist an der Organisation der Ausbildung ersichtlich. Es gibt keinen festen Durchlaufplan mehr (z.B. 5 Wochen Buchhaltung usw.), sondern die Azubis lernen agiler. Der Durchlaufplan wird nun für jeden Azubi individuell festgelegt und der Plan wird iterativ angepasst.
  • Wir hatten z.B. einen Azubis, der die kaufmännischen Inhalte zunächst als störend empfand und der einfach hacken wollte. Darauf konnten wir flexibel reagieren.
  • Das Ganze haben wir aufgezogen wie ein agiles Projekt. Zunächst haben wir evaluiert, wer unsere Stakeholder sind.
    • IHK -> Gibt das Berufsbild vor.
    • Azubis -> Wollen eine gute Ausbildung bekommen und viel lernen.
    • DATEV -> „Kunde“ der zukünftigen Mitarbeiter.
• Wie genau sieht die agile Ausbildung denn nun aus?
  • Wir sind angefangen mit den Schulungen für die IT-Azubis. Aktuell benötigte Anforderungen des Unternehmens wurden über die Schulen nicht abgedeckt. Dort wird immer noch das gleiche gelehrt wie vor 20 Jahren. Und Microsoft Office hat einfach nichts mit Informatik zu tun!
  • Daher hat DATEV einen hohen Initialaufwand, um junge Leute auf ein Level zu heben, das für die aktive Mitarbeit im Projekt reicht. Daher haben wir schon immer viel Schulungsaufwand gehabt.
  • Aber 2 Wochen C++ am Stück sind z.B. zu viel für viele Azubis. Daher haben wir die Schulungen „agilisiert“ und leichter verdaulich gemacht.
  • Der Kern der agilen Ausbildung sind Zwei-Tagesmodule, die aufeinander aufbauen. Sie haben ein einheitliches Muster. Die Schulungsinhalte stehen z.B. im „Backlog“. Ein Daily Standup gehört direkt dazu. Beim ersten Treffen wird u.a. das Vorwissen der Teilnehmer abgeklärt/abgeglichen.
  • Die Schulungen starten zu Beginn oft mit einem Rechercheauftrag. Kleine Teams (meist 2 Leute) bleiben zusammen, z.B. für diese Recherche oder ein Pair Programming.
  • Dann gibt es eine Mini-Projektaufgabe zum Umsetzen, oft z.B. Spiele für Algorithmen. Kniffel bietet sich dabei an („kleine Straße“ erkennen usw.). Das Spiel wird auch wirklich einmal gespielt, um dann User Stories daraus abzuleiten. Wie in einem echten Projekt!
  • Dann kommt die Umsetzung am Computer und eine Retrospektive am Ende jedes Bausteins. Dort klären wir u.a. was wir (Dozenten und Azubis) besser machen könnten?
• Was ist denn euer „Einstiegsbaustein“ zu Beginn der Ausbildung?
  • Es gibt einen „Selbsttest“, um den individuellen Stand der Azubis zu erfassen, z.B. in den Bereichen Coding, Java, Struktogramme verstehen, Reihenfolge von Algorithmen.
  • Am Ende gibt es dann Feedback: Wo stehen die Teilnehmer? Dann werden homogene Gruppen gebildet, die in einem gleichen Lerntempo arbeiten können. Heterogene Teams funktionieren nicht so gut, weil Fortgeschrittene Fehler der Schlechten einfach korrigieren.
  • „Logik der Programmierung“ ist dann der der erste „echte“ Baustein. Er ist ein Pflichtteil oder optional, je nach Azubi und dessen Kenntnisstand.
  • Die Bausteine bauen alle aufeinander auf. Im Standup wird immer der letzte Baustein reflektiert.
  • Es geht weiter mit Datentypen, Algorithmen, Objektorientierung, Vererbung usw. (insg. 6 Monate).
• Wie gut funktioniert dieses Vorgehen?
  • Wir fragen uns oft, ob wir noch Zeit sparen können oder ob es nicht schneller oder mit weniger Aufwand gehen könnte.
  • Die Azubis legen ein hohes Tempo vor nach der Anpassung an Scrum. Sie gewinnen an Selbstständigkeit. Gerade bei abstrakten Themen wie Vererbung sind die Schulungen fast ein Selbstläufer.
  • Die Azubis lernen das Lernen. Im letzten Block halten sie die Scrum-Meetings schon selbst. Sie verinnerlichen die Scrum-Methodik einfach.
  • Anhand der Retrospektive (1h Feedback am zweiten Tag) sieht man die Verbesserung der Azubis. Aus „Der Kaffee war gut“ und „Die Logik war mir zu technisch“ werden über die Zeit deutlich sinnvollere Kommentare und echte Anregungen und Bewertungen.
  • Die Azubis sind sehr „getriggert“ durch die Schule. Eine Aufgabe gemeinsam zu lösen und auch die eigene Selbstständigkeit müssen erst trainiert werden.
  • Es werden auch komplett andere Inhalte und fachliches Feedback von den Azubis eingebracht, z.B. SQL Island oder mehr eigene Präsentationen.
• Wird das Feedback direkt in die nächsten Bausteine eingebaut?
  • Wir haben meist mehr als drei Azubis in einer Gruppe, oft ca. 10 Leute.
  • Ein Baustein wird 3x mit unterschiedlichen Gruppen gemacht, also können wir sogar direkt das Feedback für die nächste Gruppe einfließen lassen.
  • Die Azubis bekommen mit, dass die Dozenten wirklich Feedback wollen und sich verbessern möchten und liefern dann auch konstruktives Feedback.
• Läuft die agile Ausbildung für alle IT-Berufe gleich ab?
  • Erstmal ja, aber nur bis zu einem gewissem Grad.
  • Die Kernqualifikationen der IT-Berufe sind ja überall gleich.
  • Später werden die Berufe dann getrennt nach ihren Schwerpunkten, z.B. gibt es kein UI-Design für FISIs.
• Wie sieht das Vorgehen bezogen auf ein konkretes Beispiel aus (z.B. „Einführung in relationale Datenbanken“)?
  • Solche Themen werden als einzelne Bausteine geplant und durchgeführt.
• Welche konkreten Methoden (z.B. Daily Scrum, Kanban Board) werden eingesetzt und warum?
  • Wir haben ein Kanban-Board mit Karten der Lernthemen.
• Wie und wann wird das Erreichen der Lernziele kontrolliert?
  • Es gibt permanentes Feedback während des Bausteins, z.B. live im Code. Außerdem gibt es Fragen während des Codings.
  • Am Ende einiger Bausteine gibt es auch Feedback der Dozenten für einzelne Azubis.
  • Wir führen keine schriftlichen Tests durch, da man die ja auch korrigieren müsste.
  • Die IHK-Prüfungsergebnisse geben unserem Vorgehen recht. Unsere Azubis schneiden fast immer überdurchschnittlich ab.
  • Auch später im Fachbereich gibt es eine offene Feedback-Kultur.
  • IHK-Aufgaben werden einfach in die Bausteine integriert.
• An welchem Prozess orientiert sich die agile Ausbildung grundsätzlich (z.B. Scrum)?
  • Ja, an Scrum, da es auch bei DATEV im Fachbereich etabliert ist.
  • Das Mindset passt auch einfach gut zur Ausbildung.
  • Wir haben uns auch EDUScrum angeschaut, das Scrum in die Schulen bringt inkl. Artefakte usw.
• Nehmen die Azubis während der Ausbildung besondere Rollen (z.B. Product Owner) ein?
  • Der Dozent ist Product Owner der Ausbildung. Er priorisiert die Lerninhalte für DATEV.
  • In späteren Bausteinen werden die Rollen von den Azubis eingenommen, zu Beginn ist der Dozent Scrum Master und Product Owner zusammen.
  • Das Ganze gipfelt in einer Projektwoche, in der die Rollen durchgespielt werden. Da gibt es einen Wettbewerb gegen andere Gruppen. Es wird ein „echtes“ Projekt umgesetzt.
• Woher wissen die Azubis, was sie wann lernen müssen/sollten?
  • Der Ablaufplan wird von DATEV vorgegeben.
• Wie und wie oft erfolgt eine Betreuung durch die Ausbilder?
  • Es gibt zwei Tage Schulung und dann drei Tage Fachbereich schon während der Einführung (6 Monate).
  • Während der Schulung betreut der Dozent die Azubis als Coach.
  • Es werden verschiedene Rollen eingenommen. Es gibt einen Mix aus Schulung und Eigenarbeit, je nachdem was der Einzelne gerade braucht.
• Funktioniert der Ansatz bei allen Azubis oder gibt es auch Azubis, die „klassisch“ ausgebildet werden?
  • Bislang hat es immer agil geklappt. Manchmal dauert es aber länger. FIAEs sollten das aber können, sonst ist es der falsche Beruf.
• Welche Ressourcen werden den Azubis für das selbstständige Lernen bereitgestellt?
  • Das Internet, die App Human Resouce Machine (EVA-Prinzip), viele kostenlose Inhalte, ggfs. auch kostenpflichtige Inhalte.
  • Project Euler verfolgt z.B. den Gamification-Ansatz.
  • Letztlich ist das alles aber individuell je nach Azubi.
• Welche Medien werden in der Ausbildung eingesetzt (z.B. Bücher, Podcasts, Videos, Präsenzveranstaltungen)?
  • Für jeden Baustein gibt es eine Lernzielplanung: Wie misst man den Erfolg? Was soll man lernen? Und auch: Welche Medien werden eingesetzt?
  • Das ganze ist stundenweise gegliedert, u.a. nach Erfahrung, z.B. ERM dauert 3h.
  • Der Dozent macht sich Gedanken, wie man die Inhalte gut vermitteln kann. Spontan genutzte Medien werden auch gesammelt für das nächste Mal.
  • Die Azubis haben auch schonmal eigene Lernvideos gedreht, aber die Outtakes waren das Beste daran.
  • Auch wenn man sagt „teaching is learning twice“, verwenden wir hauptsächlich Inhalte, die es schon gibt, und erstellen weniger eigene Inhalte.
• Wird der gesamte Ausbildungsrahmenplan in-house abgedeckt?
  • Die Mindestinhalte müssen halt einfach vermittelt werden, egal ob klassisch oder agil.
  • Das Berichtsheft hilft an der Stelle, um zumindest einen Eindruck zu bekommen, wem noch was fehlt.
  • Falls etwas fehlt, sollte das eigentlich im regelmäßigen Feedback auffallen. Und DATEV ist so groß, dass wir die Vermittlung dann schon organisiert bekommen.
• Wie werden die IHK-Abschlussprojekte eingebunden?
  • Die Azubis sind zu dem Zeitpunkt schon im Fachbereich unterwegs und machen normal ihre Projekte.
  • Azubis präsentieren die Ergebnisse auch untereinander und geben sich Feedback. Das läuft dann immer noch recht „agil“, aber nicht mehr als Teil der agilen Ausbildung.
• Wie fängt man an, wenn man seine Ausbildung agil(er) gestalten will?
  • Unser erster Baustein war zum Thema Datenbanken. Der Inhalt war bereits da, er war nur ohne Scrum geplant. Darauf haben wir aufgesetzt.
  • Mein Kollege war Scrum Master und wir haben zusammen die Bausteine „agilisiert“. Dazu haben wir uns im Kreativraum eingeschlossen und nach einem Tag hatten wir ein Grobkonzept. Danach haben wir dann ca. 1 Jahr nebenbei daran gearbeitet und auch mit Azubis zusammen.
  • Inzwischen sind alle IT-Schulungen auf agil umgestellt. Jetzt kommen die anderen Berufe dran!

Aus- und Weiterbildung

• Was ist dein absolutes Lieblingsbuch mit Bezug zur IT/Programmierung und warum?
  • Head First Design Patterns*: Ein richtiges „Mitmachbuch“! Man lernt spielerisch abstrakte Themen und es werden verschiedene Lerntypen angesprochen.

Abschluss

• Wo können die Hörer mehr über dich erfahren bzw. dich kontaktieren?
  • Ihr könnt euch gerne direkt an Uwe Ritthammer wenden, z.B. per E-Mail. Auf der DATEV-Website sollte die zu finden sein.
  • In den sozialen Medien ist Uwe nicht vertreten (das stielt ihm einfach zuviel Zeit).
• Schlusswort
  • Unternehmen mit Interesse an der agilen Ausbildung sollten nicht einfach die beschriebene Methode kopieren! Ihr Erfolg hängt stark von den beteiligten Personen ab und muss dem Dozenten liegen, aber auch zum Unternehmen passen!
  • Viel besser wäre es, sich selbst Gedanken zu machen und eine passende Methodik zu entwickeln. Ganz im Sinne der agilen Entwicklung!

Literaturempfehlungen

Eines von Uwes Lieblingsbüchern ist Head First Design Patterns*. Das Buch habe ich selbst auch schon gelesen (oder besser verschlungen) und kann es ebenfalls uneingeschränkt weiterempfehlen. Gut verdaulich und praxis- bzw. teilweise sogar prüfungsrelevant.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• DATEV, die „Erfinder“ der agilen Ausbildung.
• Ausbildung bei DATEV
• Podcast „Stay Forever“, der sich mit der Glorie alter Computer- und Videospiele beschäftigt.
• eduScrum Start versucht Scrum in die Schulen zu bringen.
• SQL Island, ein Adventure, das man mittels SQL bestreitet.
• Human Resource Machine, ein Spiel zum Einstieg in das EVA-Prinzip.
• Project Euler, eine Website mit Logik- und Matherätseln zum Programmieren.
• Agiles Manifest, das die Grundlagen der agilen Softwareentwicklung beschreibt.

Der Beitrag Agile Ausbildung bei DATEV mit Uwe Ritthammer – IT-Berufe-Podcast #153 erschien zuerst auf IT-Berufe-Podcast.

Eine umfangreiche Checkliste mit allem, was du zur mündlichen IHK-Prüfung (Projektpräsentation und Fachgespräch) mitbringen solltest, gibt es in der einhundertvierundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Der Tag der Projektpräsentation ist sicher für viele Prüflinge stressig. Es geht ja immerhin um nichts weniger als den (meist ersten) Berufsabschluss und die letztendliche Abschlussnote. Da sollte man sich als Prüfling nicht noch unnötig zusätzlich Stress verursachen durch vergessene wichtige Unterlagen oder Utensilien, die unbedingt bei dieser letzten Prüfung benötigt werden.

Um es dir etwas einfacher zu machen, kommt hier meine ultimative Liste aller Dinge, die du zur Prüfung mitbringen bzw. vorher erledigen solltest.

• Unterlagen
  • Prüfungseinladung der IHK: Mitbringen, damit der Prüfungsausschuss dich identifizieren kann.
  • Gültigen Personalausweis: Mitbringen, damit der Prüfungsausschuss dich identifizieren kann. Auch falls du dem Prüfungsausschuss persönlich bekannt bist, weil z.B. dein Lehrer teilnimmt. Er könnte am Prüfungstermin krank sein.
  • Ausbildungsnachweis: Das allseits beliebte Berichtsheft bzw. ein Projektbericht bei externen Prüflingen oder dualen Studenten solltest du auf Papier in einem vernünftig prüfbaren Format (z.B. Schnellhefter) dabei haben. Ohne das Berichtsheft wirst du nicht geprüft!
  • Zeugnis der Berufsschule: Falls du deine Abschlussnote mit auf das IHK-Zeugnis drucken lassen willst.
• Technik
  • Laptop mit deiner Projektpräsentation: Vorher nochmal testen, ob alle verwendeten Schriftarten, Bilder, Videos usw. eingebettet oder korrekt verknüpft sind. Kein „witziges“ oder unpassendes Hintergrundbild einstellen. Desktop vorher aufräumen.
  • Presenter*: Damit du nicht ständig zum Laptop rennen musst, um die Folien durchzuschalten, und etwas in der Hand hast, an dem du dich festhalten kannst. Nutze nicht dein Handy (ist verboten) oder deine Maus (du kannst dich „verklicken“).
  • VGA-/DVI-/HDMI-Kabel bzw. -Adapter für deinen Laptop: Oft gibt es Probleme mit dem Beamer vor Ort, der nicht den erwarteten Anschluss hat.
  • Eigener Beamer: Nicht nur falls in deinem Prüfungsraum kein Beamer bereitgestellt wird. Der kann durchaus kaputt sein oder zu lichtschwach.
  • Programmierte Anwendung bzw. dein Projektartefakt: Falls du sie live demonstrieren willst, wovon ich aber in den meisten Fällen abraten würde.
• Sonstiges
  • Wasser: Oder irgendetwas anderes zu trinken. Viele Prüflinge haben durch die Aufregung einen trockenen Hals und das ist für den Vortrag nicht gerade förderlich.
  • Nervennahrung: Schokoriegel oder lieber eine gesunde Nussmischung verkürzt die Wartezeit bis zur Prüfung.
  • Vernünftige Kleidung: Nicht „overdressed“, aber schicke Klamotten wie Hemd oder Bluse sind schon angebracht.
• Fallback
  • Projektpräsentation: Deine Präsentation solltest du auf einem USB-Stick und/oder in der Cloud ablegen, falls dein Laptop den Geist aufgibt oder du Probleme mit dem Beamer bekommst.
  • Projektdokumentation: Zumindest digital solltest du deine Projektdokumentation griffbereit haben, falls es Rückfragen zu deinen Inhalten gibt.
  • Handout der Präsentation: Als Backup falls die gesamte Technik versagt. Nicht für jeden Prüfer ausdrucken!
  • Timer*: Alternativ eine Uhr als Fallback für den nicht funktionierenden Präsentationsmodus in PowerPoint.
  • Karteikarten/Vortragshilfen: Solltest du dich sicherer fühlen, kannst du statt des Präsentationsmodus auch Handkarten verwenden.
• Vorbereitung
  • Standardfragen: Gut vorbereitete Antworten auf die klassischen Fragen im Fachgespräch solltest du auswendig im Kopf haben.
  • Prüfungsraum begutachten: Wenn es dir möglich ist, kannst du vielleicht sogar deine Präsentation vor Ort live durchspielen. Nur so kannst du sicher sein, dass aus der späteren Position der Prüfer heraus alle Texte gut lesbar (Schriftgröße usw.) und Grafiken erkennbar (Kontrast usw.) sind.
  • Zeit: Komm lieber deutlich zu früh zur Prüfung als ein wenig zu spät. Wir konnten z.B. schon öfter Prüflinge spontan um eine Stunde vorziehen, weil andere ausgefallen sind oder ihr Berichtsheft vergessen haben. Da macht es einen guten Eindruck, wenn du spontan reagieren kannst und bereitstehst.

Download der Checkliste

Hier kannst du dir die obige Checkliste in Kurzform zum Ausdrucken herunterladen: Checkliste für die Projektpräsentation und das Fachgespräch der IHK-Prüfung.

Produktempfehlungen

Ich nutze seit Jahren den Logitech R700 Professional Presenter* und kann ihn uneingeschränkt weiterempfehlen.

*

Ob als Pomodoro-Timer oder als Countdown bei Präsentationen, ich nutze fast täglich den TFA 38.2025 elektronischen 2-fach Timer*.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Warum du bei deiner Projektpräsentation unbedingt einen Presenter nutzen solltest
• Kleiderordnung bei der Abschlussprüfung (Projektpräsentation und Fachgespräch)
• Meine Hörbücher zur Vorbereitung auf das Fachgespräch
• Live-Demo in der Projektpräsentation
• Handout zur Projektpräsentation
• Einhaltung der Vortragszeit (15 Minuten) bei der Projektpräsentation

Weitere Infos zur Projektpräsentation

Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.

Der Beitrag Checkliste für die Projektpräsentation und das Fachgespräch der IHK-Prüfung – IT-Berufe-Podcast #154 erschien zuerst auf IT-Berufe-Podcast.

Um die Vorteile und Einsatzgebiete von Plain-Text-Markup-Formaten für längere Texte geht es in der einhundertfünfundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Plain-Text-Formate sind Formate, die in reinen (menschenlesbaren) Text-Dateien abgelegt werden, also keine binären Formate wie z.B. in Microsoft Word oder LibreOffice.

Vorteile von Plain-Text-Formaten

• Versionierung: Diff, Merge, Branches möglich
• Langlebigkeit: Keine proprietäre Bearbeitungssoftware nötig, keine Abhängigkeit von Herstellern
• Produktivität: Arbeit ausschließlich mit der Tastatur ohne Maus
• Flexibilität: Konvertierbar, zur Not selbst parsbar, mit jedem beliebigen Editor änderbar
• Automatisierung: Mächtige Tools zur Manipulation vorhanden

Beispiele für Formate

• Markdown
  • leicht zu lernen, geringer Sprachumfang
  • Output hauptsächlich HTML
  • breite Unterstützung in Tools, z.B. WordPress, GitHub
• AsciiDoc
  • sehr großer Sprachumfang, sogar geeignet für Bücher
  • viele verschiedene Output-Formate, z.B. HTML, PDF, EPUB
  • gut in übliche Build-Prozesse integriert, z.B. in Gradle
• Textile
  • ähnelt der Wiki-Syntax
  • Redmine
• LaTeX
  • komplettes Textsatz-System, „perfekter“ Textsatz
  • geeignet für komplette Bücher inkl. Verzeichnissen, Index, Literaturverzeichnis
• PlantUML
  • Gestaltung von UML-Diagrammen
  • kann u.a. in LaTeX und AsciiDoc eingebunden werden, aber auch in Wikis

Tools

• Pandoc: Konvertiert automatisch Dateien zwischen beliebigen Formaten
• VSCode: Editor für beliebige Markup-Formate inkl. Preview-Funktion
• MarkdownPad: Editor für Markdown

Quelltextbeispiele

Es folgen Beispiele für das gezeigte HTML-Fragment in den unterschiedlichen Markup-Sprachen.

HTML

<h1 id="markup-sprachen-markdown">Markup-Sprachen: HTML</h1>
<p>Ein normaler Absatz in HTML.</p>
<h2 id="überschrift">Überschrift</h2>
<p><strong>Fetter Text</strong> und <em>kursiver Text</em>.</p>
<h2 id="listen">Listen</h2>
<ul>
<li>Ungeordnete Liste
<ul>
<li>Mit Unterpunkten</li>
<li>Noch ein Unterpunkt</li>
</ul></li>
<li>Noch ein Punkt</li>
</ul>
<ol type="1">
<li>Geordnete Liste
<ol type="1">
<li>Mit Unterpunkten</li>
<li>Noch ein Unterpunkt</li>
</ol></li>
<li>Noch ein Punkt</li>
</ol>
<h2 id="links">Links</h2>
<p><a href="https://it-berufe-podcast.de" title="Website des IT-Berufe-Podcasts">IT-Berufe-Podcast</a></p>
<h2 id="bilder">Bilder</h2>
<figure>
<img src="https://it-berufe-podcast.de/Abbildungen/LogoITBerufePodcast500px.jpg" title="Das Logo des IT-Berufe-Podcasts" alt="" /><figcaption>Bildbeschreibung</figcaption>
</figure>
<h2 id="code">Code</h2>
<p>Inline Code mit <code>code</code>.</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode java"><code class="sourceCode java"><span id="cb1-1"><a href="#cb1-1"></a><span class="kw">public</span> <span class="dt">static</span> <span class="dt">void</span> <span class="fu">main</span>(<span class="bu">String</span>[] args) {</span>
<span id="cb1-2"><a href="#cb1-2"></a>  <span class="bu">System</span>.<span class="fu">out</span>.<span class="fu">println</span>(<span class="st">"Hallo!"</span>);</span>
<span id="cb1-3"><a href="#cb1-3"></a>}</span></code></pre></div>
<h2 id="zitate">Zitate</h2>
<blockquote>
<p>Zitate sehen so aus.</p>
</blockquote>

Markdown

# Markup-Sprachen: Markdown

Ein normaler Absatz in Markdown.

## Überschrift

**Fetter Text** und *kursiver Text*.

## Listen

* Ungeordnete Liste
  * Mit Unterpunkten
  * Noch ein Unterpunkt
* Noch ein Punkt

1. Geordnete Liste
    1. Mit Unterpunkten
    2. Noch ein Unterpunkt
2. Noch ein Punkt

## Links

[IT-Berufe-Podcast](https://it-berufe-podcast.de "Website des IT-Berufe-Podcasts")

## Bilder

![Bildbeschreibung](https://it-berufe-podcast.de/Abbildungen/LogoITBerufePodcast500px.jpg "Das Logo des IT-Berufe-Podcasts")

## Code

Inline Code mit `code`.

\```java
public static void main(String[] args) {
  System.out.println("Hallo!");
}
\```

## Zitate

> Zitate sehen so aus.

AsciiDoc

== Markup-Sprachen: AsciiDoc

Ein normaler Absatz in AsciiDoc.

=== Überschrift

*Fetter Text* und _kursiver Text_.

=== Listen

* Ungeordnete Liste
** Mit Unterpunkten
** Noch ein Unterpunkt
* Noch ein Punkt

. Geordnete Liste
.. Mit Unterpunkten
.. Noch ein Unterpunkt
. Noch ein Punkt

=== Links

https://it-berufe-podcast.de[IT-Berufe-Podcast]

=== Bilder

image:https://it-berufe-podcast.de/Abbildungen/LogoITBerufePodcast500px.jpg[Bildbeschreibung,title="Das Logo des IT-Berufe-Podcasts"]

=== Code

Inline Code mit `code`.

[source,java]
----
public static void main(String[] args) {
  System.out.println("Hallo!");
}
----

=== Zitate

____
Zitate sehen so aus.
____

Textile

h1(#markup-sprachen-markdown). Markup-Sprachen: Textile

Ein normaler Absatz in Textile.

h2(#überschrift). Überschrift

*Fetter Text* und _kursiver Text_.

h2(#listen). Listen

* Ungeordnete Liste
** Mit Unterpunkten
** Noch ein Unterpunkt
* Noch ein Punkt

# Geordnete Liste
## Mit Unterpunkten
## Noch ein Unterpunkt
# Noch ein Punkt

h2(#links). Links

"IT-Berufe-Podcast":https://it-berufe-podcast.de

h2(#bilder). Bilder

!https://it-berufe-podcast.de/Abbildungen/LogoITBerufePodcast500px.jpg(Das Logo des IT-Berufe-Podcasts)!
Bildbeschreibung

h2(#code). Code

Inline Code mit @code@.

bc(java). public static void main(String[] args) {
  System.out.println("Hallo!");
}


h2(#zitate). Zitate

bq. Zitate sehen so aus.

LaTeX

\hypertarget{markup-sprachen-markdown}{%
\section{Markup-Sprachen: LaTeX}\label{markup-sprachen-markdown}}

Ein normaler Absatz in LaTeX.

\hypertarget{uxfcberschrift}{%
\subsection{Überschrift}\label{uxfcberschrift}}

\textbf{Fetter Text} und \emph{kursiver Text}.

\hypertarget{listen}{%
\subsection{Listen}\label{listen}}

\begin{itemize}
\tightlist
\item
  Ungeordnete Liste

  \begin{itemize}
  \tightlist
  \item
    Mit Unterpunkten
  \item
    Noch ein Unterpunkt
  \end{itemize}
\item
  Noch ein Punkt
\end{itemize}

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\tightlist
\item
  Geordnete Liste

  \begin{enumerate}
  \def\labelenumii{\arabic{enumii}.}
  \tightlist
  \item
    Mit Unterpunkten
  \item
    Noch ein Unterpunkt
  \end{enumerate}
\item
  Noch ein Punkt
\end{enumerate}

\hypertarget{links}{%
\subsection{Links}\label{links}}

\href{https://it-berufe-podcast.de}{IT-Berufe-Podcast}

\hypertarget{bilder}{%
\subsection{Bilder}\label{bilder}}

\begin{figure}
\centering
\includegraphics{https://it-berufe-podcast.de/Abbildungen/LogoITBerufePodcast500px.jpg}
\caption{Bildbeschreibung}
\end{figure}

\hypertarget{code}{%
\subsection{Code}\label{code}}

Inline Code mit \texttt{code}.

\begin{Shaded}
\begin{Highlighting}[]
\KeywordTok{public} \DataTypeTok{static} \DataTypeTok{void} \FunctionTok{main}\NormalTok{(}\BuiltInTok{String}\NormalTok{[] args) \{}
  \BuiltInTok{System}\NormalTok{.}\FunctionTok{out}\NormalTok{.}\FunctionTok{println}\NormalTok{(}\StringTok{"Hallo!"}\NormalTok{);}
\NormalTok{\}}
\end{Highlighting}
\end{Shaded}

\hypertarget{zitate}{%
\subsection{Zitate}\label{zitate}}

\begin{quote}
Zitate sehen so aus.
\end{quote}

PlantUML

Und zum Schluss noch ein Beispiel für ein Klassendiagramm in PlantUML.

class Auto {
    hersteller : String
    farbe : String
    kilometerstand : Integer
    neupreis : Double

    fahre() : void
    hupe() : void
}

Gerendert sieht das dann so aus.

Literaturempfehlungen

Eines meiner absoluten Lieblingsbücher widmet ein eigenes Kapitel dem Thema „Plain Text“: The Pragmatic Programmer*. Dave Thomas und Andy Hunt erklären dir auch noch einmal die Vorteile von einfachen Textdateien.

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Markdown
• AsciiDoc
• Textile
• LaTeX
• PlantUML
• Pandoc
• Visual Studio Code
• MarkdownPad

Der Beitrag Plain-Text-Markup-Formate für Texte (Markdown, Asciidoc) – IT-Berufe-Podcast #155 erschien zuerst auf IT-Berufe-Podcast.

In dieser Sonder-Episode des IT-Berufe-Podcasts geht es um drei Stellenausschreibungen für Softwareentwickler und Systemadministratoren bei meinem Arbeitgeber.

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 drei Stellen aus: zwei Softwareentwickler und einen Systemadministrator. Selbstverständlich sind Bewerbungen von Personen aller Geschlechter erwünscht.

Kurzübersicht der Stellen

• Bezeichnung: Softwareentwickler (m/w/d) bzw. Systemadministrator (m/w/d)
• Art der Anstellung: unbefristete Festanstellung
• Arbeitsort: ALTE OLDENBURGER Krankenversicherung AG, Alte-Oldenburger-Platz 1, 49377 Vechta
• Beginn: schnellstmöglich
• Ende der Bewerbungsfrist: 05.07.2020
• Gehalt: attraktive Vergütung nach dem Tarifvertrag für das private Versicherungsgewerbe
• Sonderleistungen: Urlaubs- und Weihnachtsgeld (13,3 Gehälter), Fahrtkostenzuschuss zur Arbeitsstelle, 40 EUR vermögenswirksame Leistungen pro Monat, Firmenfitness über qualitrain, Mitarbeiterrabatte für Versicherungen, arbeitgeberfinanzierte Direktversicherung
• Wöchentliche Arbeitszeit: 38 Stunden im Gleitzeitmodell ohne Kernarbeitszeit (bei einer Vollzeitbeschäftigung)
• Jährlicher Urlaubsanspruch: 30 Tage
• Weiterbildungsmöglichkeiten: (Duales) Studium (z.B. Wirtschaftsinformatik, technische Informatik), IHK-Weiterbildungen, externe Technologieschulungen, Konferenzbesuche
• Sonstiges: frisches Obst, kostenloser Kaffee, modern und ergonomisch ausgestattete Arbeitsplätze in max. 4er-Büros, 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 mit SonarQube
  • Java 14, Jakarta EE 8, JBoss EAP 7.3
• 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

Detailinformationen zu den drei Stellenangeboten

Unter den folgenden Links kannst du dir alle Details zu den ausgeschriebenen Stellen anschauen und findest auch die notwendigen Daten für deine Bewerbung bei uns.

Softwareentwickler für Java-Services

Softwareentwickler im Versicherungsbereich

Systemadministrator im DevOps-Bereich

Softwareentwickler für Java-Services

Wir suchen Softwareentwickler für die Service-Entwicklung und die Erweiterung unseres Bestandsführungssystems. Deine Schwerpunkte liegen im Bereich der Java-Entwicklung und im Enterprise Service Bus (Integration Server von webMethods). Du entwickelst REST-APIs und (Web-)Anwendungen sowie die passenden Backend-Programme im Bestandsführungssystem.

Die verschiedenen Systeme unserer Infrastruktur (z.B. Bestandsführung, Dokumentenmanagement, Output-Management) kommunizieren über REST-Services miteinander. Hier haben wir aktuell und in Zukunft noch Ausbaubedarf, insbesondere im Bereich Online-Abschluss und App-Anbindung.

Dreh- und Angelpunkt der Systemkommunikation ist unser Enterprise Service Bus, der Integration Server (IS) von webMethods. Zusätzlich zum Coding in Java wirst du dich daher auch mit der internen Programmiersprache Flow des ESBs beschäftigen. Flow ist eine grafische Programmiersprache, die als Ziel die möglichst einfache Integration von Datenströmen aus und in Services hat. Der IS erlaubt darüber hinaus auch noch die native Programmierung in Java. Diese Möglichkeit nutzen wir insbesondere für komplexere Services, die über die reine Integration hinweg noch Logik enthalten. Alle Services sind mit automatisierten Unit- und Integrationstests abgedeckt und das Deployment ist vollständig automatisiert.

Und damit im Kernsystem der AO, dem Bestandsführungssystem VERSIS, auch die entsprechenden Daten ankommen, wirst du darüber hinaus in der Programmiersprache Natural die passenden Backend-Module entwickeln. Dich erwartet also ein abwechslungsreiches und herausforderndes Aufgabengebiet, in dem du dich technologisch ausleben kannst.

Natural ist eine Programmiersprache der Software AG, dem zweitgrößten Softwareunternehmen Deutschlands nach SAP. Obwohl die Sprache schon ein wenig älter ist, verwenden wir in der AO die modernste Entwicklungsumgebung aller Natural-Kunden. Wir setzen auf Eclipse als Entwicklungsumgebung und haben den gesamten Build mit Gradle, Jenkins und sogar SonarQube automatisiert. Wir stehen kurz davor, sowohl den Build als auch den Betrieb unserer Kernanwendung in Docker zu realisieren. Und da wir Wert auf Qualitätssicherung und Test Driven Development legen, haben wir sogar unser eigenes Unit-Test-Framework für Natural entwickelt.

Nach Natural ist Java die Standard-Programmiersprache, mit der bei der AO Anwendungen entwickelt werden. Wir haben bereits mehrere Anwendungen mit Java und Jakarta EE auf JBoss EAP als Application-Server umgesetzt. Auch in der Ausbildung bei der AO wird Java als Standardsprache vermittelt. Für unsere Eigenentwicklungen setzen wir auf die jeweils aktuellste Java-Version, zur Zeit also Java 14 bzw. Java 11 in Verbindung mit Jakarta EE 8 und JBoss EAP 7.3. Im Integration Server verwenden wir noch Java 8, aber für Mitte 2020 ist bereits ein Upgrade der Plattform auf Java 11 geplant. Für Unit-Tests setzen wir auf JUnit 5 mit AssertJ-Matchern. Als IDE verwenden wir für Natural, Java und den Integration Server Eclipse.

Wir setzen auf eine moderne technische Infrastruktur für unsere Softwareentwicklung. Alle Projekte werden automatisiert in Jenkins und im Java-Bereich auch bereits komplett in Docker-Containern gebaut. Statische Code-Analyse mit SonarQube gehört genauso zum Alltag des Softwareentwicklers wie die Automatisierung des Builds mit Gradle. Als Versionsverwaltungssystem setzen wir Git ein und für die Artefakte Artifactory. Wir hosten die gesamte Infrastruktur bei uns im Haus.

Der Bereich DevOps wächst aktuell sehr stark und wir werden hier in Zukunft noch einiges investieren. Unser Ziel ist es, dass alle Softwareentwickler, egal mit welcher Programmiersprache sie arbeiten, eine Infrastruktur nutzen können, die sie optimal bei ihrer täglichen Arbeit unterstützt. Lange Feedbackzyklen und ungetestete Releases sollen der Vergangenheit angehören. Programmierpraktiken wie Test Driven Development, Pair Programming, Code Reviews und Pull Requests werden zu deinem Alltag gehören.

Softwareentwickler im Versicherungsbereich

Du hast Lust auf die Entwicklung von versicherungstechnischen Anwendungen in einer modernen IT-Infrastruktur und suchst einen spannenden Job, in dem du deine Programmier-Skills zeigen und flexibel arbeiten kannst?

Die Abteilung IT-Produktmodellierung bildet die Produkte der AO – die Versicherungstarife – in den IT-Systemen ab, d.h. sie führt die technische Modellierung der Tarife durch. Dabei geht es zum Einen darum, die Produkt- bzw. Tarif-Daten in die entsprechenden Datenstrukturen abzulegen. Hier stellen wir mehr und mehr auf automatisierte Lösungen um, welche wir selbst entwickeln.

Weiter ist die Implementierung der Tarif-Berechnungen ein wesentlicher Bestandteil des Aufgabengebiets in unserer Abteilung. Die fachlichen Vorgaben dafür kommen aus der Abteilung Mathematik, welche die Tarife auch kalkuliert. Das bedeutet, dass gerade mit dieser Abteilung eine enge Zusammenarbeit besteht. Aber auch zum Fachbereich und natürlich zu den anderen IT-Abteilungen haben wir einen intensiven Austausch.

Ferner kümmern wir uns auch um die Implementierung der Tarif-Prozesssteuerung. Diese Prozesse sorgen dafür, dass die Tarif-Berechnungen mit den richtigen Tarif-Daten und Kunden-Daten korrekt ausgeführt werden.

Einen großen Teil unserer Arbeit nimmt die Durchführung von Bestandsprozessen wie der Beitragsanpassung ein: Für alle bzw. sehr viele Verträge im Bestand wird eine Vertragsänderung ausgeführt, welche wiederum verschiedenste Tarif-Berechnungen beinhaltet.

Wir suchen einen erfahrenen Softwareentwickler, der uns bei den beschriebenen Tätigkeiten und darüber hinaus unterstützt.

Systemadministrator für den DevOps-Bereich

Du hast Lust auf die Administration einer modernen mit VMWare und Citrix virtualisierten Microsoft- und Linux-Infrastruktur und suchst einen spannenden Job, in dem du deine Skills zeigen und flexibel arbeiten kannst?

Du übernimmst die Verantwortung für die Administration unserer Linux-Server. Unsere wesentlichen Systeme z.B. für die Bestandsführung, das Workflow- und Dokumentenmangement und weitere (über 40 Server) laufen unter SUSE Linux. Du verantwortest den Betrieb und Support dieser Infrastruktur. Dabei stellst du die zugehörige Performance, Wartbarkeit und Skalierbarkeit sicher. Neben Linux wird auch Windows für andere Server und hauptsächlich als Client-Betriebssystem genutzt.

Als DevOps-Spezialist gestaltest du eine neue Container-basierte Anwendungs-Infrastruktur (Docker) und begleitest diese von der Konzeption bis hin zur Inbetriebnahme. Hierbei bringst du deine vorhandenen Kenntnisse und Erfahrungen aktiv ein und arbeitest eng mit den Kollegen aus allen IT-Abteilungen zusammen. Zudem betreibst und erweiterst du die vorhandene Infrastruktur für automatisierte Builds mit Jenkins, Git, Gradle und Artifactory für unsere Softwareentwicklung.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Softwareentwickler (m/w/d) für Java-Services bei der ALTE OLDENBURGER Krankenversicherung AG in Vechta
• Softwareentwickler (m/w/d) für den Versicherungsbereich bei der ALTE OLDENBURGER Krankenversicherung AG in Vechta
• Systemadministrator (m/w/d) für den DevOps-Bereich bei der ALTE OLDENBURGER Krankenversicherung AG in Vechta

Der Beitrag Stellenangebote Softwareentwicklung und Systemadministration in Vechta – IT-Berufe-Podcast erschien zuerst auf IT-Berufe-Podcast.

Um den effektiven Umgang mit Suchmaschinen wie Google zur Recherche von Informationen geht es in der einhundertsechsundfünfzigsten Episode des IT-Berufe-Podcasts.

Inhalt

• Warum ist die richtige Suche im Internet wichtig?
  • Reines Faktenwissen ist nicht mehr zeitgemäß. Dafür haben wir Suchmaschinen.
  • Die „falsche“ Suche führt dich ggfs. zu veralteten oder falschen Informationen. Das behindert dich in der täglichen Arbeit.
  • Gerade für ITler ist die Suchmaschine ein tägliches Werkzeug. Wir können nicht alle Programmiersprachen oder Konfigurationseinstellungen auswendig kennen.
  • Es ist wichtig, dass du deinen Verstand bemühst und die Ergebnisse bewertest. Überlass der Suchmaschine nicht das Denken für dich!
• Wie „google“ ich richtig? Allgemeine Tipps zum Umgang mit Suchmaschinen.
  • Denk nicht wie ein Mensch, sondern wie eine Maschine! Formuliere also keine Prosatexte, sondern kurze und knappe Suchanfragen mit den wichtigsten Suchbegriffen. Statt „Wie öffne ich eine Datei in Java?“ solltest du nach „java datei öffnen“ suchen.
  • Suche so spezifisch wie möglich, indem du einschränkende weitere Suchbegriffe hinzufügst. Statt „java dateiverarbeitung“ solltest du nach „java datei schreiben anhängen“, wenn du etwas an eine Datei anhängen möchtest.
  • Verwende gerade im IT-Umfeld Englisch als Sprache für deine Suchanfragen. Das wird zu deutlich mehr Ergebnissen führen. Statt „java datei öffnen“ solltest du also nach „java file open“ suchen.
  • Vermeide sogenannte Stopwords und Satzzeichen, die von der Suchmaschine ohnehin ignoriert werden. Statt „how do i open a file in java?“ solltest du also nach „java file open“ suchen.
  • Manchmal kann es sinnvoll sein, „anonym“ zu suchen, damit die Suchergebnisse nicht anhand deines Profils angepasst werden oder die Suchmaschine ein solches von dir erstellt.
• Produktivitätstipps
  • Ignoriere Groß-/Kleinschreibung bei deiner Suche. Die Suchmaschine ignoriert das eh.
  • Stelle deine Browser-Suche direkt auf deine Standard-Suchmaschine ein, z.B. Google. Dadurch kannst du durch die Eingabe von Suchbegriffen in der Adresszeile direkt eine Suche starten.
  • Richte dir Such-Abkürzungen für häufig verwendete Suchmaschinen im Browser ein. Dadurch kannst du mit wenigen Tastendrücken direkt in der gewünschten Suchmaschine suchen. Das geht auch für interne Anwendungen wie dein Ticket-System.
    
  • Es gibt nicht nur Google! Je nachdem, was du suchst, kann die direkte Suche bei YouTube oder Amazon sinnvoller sein. Und wenn du umweltbewusster suchen willst, empfehle ich dir Ecosia.
  • Es gibt nicht nur Google! Je nachdem, was du suchst, kann die direkte Suche bei YouTube oder Amazon sinnvoller sein.
• Bewertung von Suchergebnissen
  • Unterscheide zwischen organischen und bezahlten Suchergebnissen. Erstere sind meist die bessere Wahl.
  • Platz 1 ist nicht automatisch das beste Ergebnis für dich. Viele Websites verdienen ihr Geld mit Suchmaschinenoptimierung und tun alles dafür, auf den ersten Plätzen zu landen. Sie müssen aber nicht unbedingt den besten Inhalt bieten.
  • Öffne auch mal die zweite Suchergebnisseite. Im sogenannten Long Tail verbergen sich durchaus auch Perlen.
  • Achte auf das Erstelldatum der Seite. Gerade in der IT sind aktuelle Inhalte wichtig.
  • Achte auf korrekte Versionen der verwendeten Software. Eine Anleitung zu Java 6 hilft dir nicht, wenn du mit Java 11 arbeitest.
• (Google-)Suchoperatoren zur treffgenaueren Suche
  • Unpassende Wörter ausschließen: -. Beispiel: javascript dom -react
  • Exakt passende Treffer (wörtliche Suche): "". Beispiel: „Einhaltung der Präsentationszeit“ fachinformatiker
  • Bestimmte Website durchsuchen: site:. Beispiel: site:it-berufe-podcast.de presenter
  • Seiten mit Verlinkung auf Zielseite suchen: link:. Beispiel: link:it-berufe-podcast.de
  • Konkreten Bestandteil der URL suchen: inurl:. Beispiel: projektdokumentation inurl:gerda
  • Konkreten Dateityp suchen: filetype:. Beispiel: filetype:pdf projektdokumentation vorlage
  • Schnell kurze Definitionen finden: define:. Beispiel: define:REST
• Zusätzliche Möglichkeiten der Google-Suche
  • Bilder-Rückwärtssuche, z.B. für Quellenangaben bei verwendeten Bildern.
  • Währungs- und Taschenrechner. Beispiele: 100 usd in eur oder 19 * (3 + 2) / 100
  • Alte Versionen von Websites anzeigen (cache:).

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Mit Google suchen – Google-Suche-Hilfe
• Websuchen optimieren – Google-Suche-Hilfe: Liste der möglichen Suchoperatoren bei Google
• 27+ Google Suchoperatoren für bessere Suchergebnisse: noch mehr mögliche Suchoperatoren
• Richtig googeln: So nutzt ihr die Google-Suchoperatoren

Der Beitrag Effektive Informationsrecherche mit Suchmaschinen (insb. Google) – IT-Berufe-Podcast #156 erschien zuerst auf IT-Berufe-Podcast.

Leon Brachwitz hat in der Sommerprüfung 2020 von der IHK Oldenburg 95% für die Projektdokumentation seiner betrieblichen Projektarbeit bekommen. Herzlichen Glückwunsch zu dieser tollen Leistung!

Leon war so nett, die Arbeit der Allgemeinheit zur Verfügung zu stellen. Du kannst sie hier herunterladen.

Bewertung

Die Projektdokumentation ist ein sehr gutes Beispiel für eine Projektarbeit. Insbesondere folgende Punkte fallen mir positiv auf:

• Die Projektarbeit hat ein modernes und anspruchsvolles Thema: die Implementierung einer kompletten Webanwendung.
• Das Thema ist nachvollziehbar erläutert und gut begründet.
• Das Projekt wird ausführlich und nachvollziehbar auf seine Wirtschaftlichkeit geprüft.
• Alle Projektphasen werden in der Dokumentation behandelt.
• Die Projektphasen werden mit passenden Artefakten (User-Stories, Lastenheft, Pflichtenheft usw.) dokumentiert.
• Die Projektphasen sind gut aufgeteilt und haben einen passenden Umfang.
• Es werden viele passende technische Methodiken (ERM, Tabellenmodell usw.) angewendet und die Software wird professionell entwickelt.
• Die Dokumentation macht einen professionellen Eindruck mit sauberen Seitenzahlen, Kopf- und Fußzeile, Verzeichnissen usw.
• In der Kostenkalkulation werden auch laufende Kosten berücksichtigt.
• Nicht selbst erarbeitete Inhalte werden korrekt mit Zitaten und Quellenangaben gekennzeichnet.
• Zur Qualitätssicherung werden direkt bei der Implementierung auch Unit-Tests programmiert.
• Es wird interessanter (!) Code verschiedener Technologien (Java, JavaScript, JSF) gezeigt.
• Alle erwarteten Dokumentationen (Benutzer und Entwickler) sind vorhanden.
• Die Oberflächenentwürfe wurden mit der Hand gezeichnet. Eine willkommene Abwechslung zu den üblichen Mockup-Tools.
• Maßnahmen zur Qualitätssicherung werden explizit eingeplant und umfangreich durchgeführt und dokumentiert.
• Das Projekt wird durchgängig automatisiert (Build/Deployment mit Gradle und Jenkins) und in Docker-Containern betrieben.
• Verwendete Akronyme werden im umfangreichen Abkürzungsverzeichnis erläutert.
• Auf die Qualitätssicherung wurde besonders Wert gelegt (SonarQube, Pull Requests).
• Die Wirtschaftlichkeitsbetrachtung ist umfangreich und gut nachvollziehbar.
• Die Vorgaben der IHK (15 Seiten + 25 Seiten Anhang) werden exakt eingehalten.

Metadaten

• Titel der Projektarbeit: AO-Pflegerechner – Web-Anwendung für die Beratung in der Pflegezusatzversicherung
• Ausbildungsberuf: Fachinformatiker Anwendungsentwicklung
• Prüfung: Sommerprüfung 2020
• Bewertung: 95%
• IHK: IHK Oldenburg
  • Vorgaben der IHK: Max. 15 Seiten Fließtext ohne Deckblatt und Verzeichnisse + 25 Seiten Anhang
• Name des Prüflings: Leon Brachwitz
  • Kontaktmöglichkeiten: Website, Facebook, Instagram, Twitter
• Ausbildungsbetrieb: ALTE OLDENBURGER Krankenversicherung AG
  • Kontaktmöglichkeiten: Website, Facebook, Instagram, Xing

Wenn du deine Projektarbeit auch auf dieser Seite veröffentlichen möchtest, dann sprich mich gerne an. Ich suche (sehr gute) Beispiele aus allen IT-Berufen.

Download

Vielen Dank an Leon Brachwitz und ALTE OLDENBURGER Krankenversicherung AG für das Bereitstellen der Projektdokumentation. Alle internen Angaben oder personenbezogenen Daten wurden entweder unkenntlich gemacht oder durch fiktive Werte ersetzt.

• Projektdokumentation Fachinformatiker Anwendungsentwicklung von Leon Brachwitz (IHK Oldenburg, Sommerprüfung 2020)
  

Weitere Infos zur Projektdokumentation

Du suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.

Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.

Der Beitrag Projektdokumentation von Leon Brachwitz (mit 95% bewertet) erschien zuerst auf IT-Berufe-Podcast.

Leon Brachwitz hat in der Sommerprüfung 2020 von der IHK Oldenburg 100% für die Projektpräsentation seiner betrieblichen Projektarbeit bekommen. Herzlichen Glückwunsch zu dieser tollen Leistung!

Leon war so nett, die Arbeit der Allgemeinheit zur Verfügung zu stellen. Du kannst sie hier herunterladen.

Bewertung

Die Projektpräsentation ist ein sehr gutes Beispiel für eine Projektarbeit. Insbesondere folgende Punkte fallen mir positiv auf:

• Die Projektarbeit hat ein modernes und anspruchsvolles Thema.
• Das Thema ist nachvollziehbar erläutert und gut begründet.
• Die Problemstellung wird mit grafischen Abläufen illustriert.
• Zu jeder Projektphase wird das passende Artefakt (Use-Cases, Lastenheft usw.) erwähnt und (in Ausschnitten) gezeigt.
• Es werden viele passende Methodiken (Klassendiagramm, ERM usw.) angewendet und die Software wird professionell entwickelt.
• Es wird auch Code gezeigt, der Schritt für Schritt aufgebaut wird.
• Die Gliederung der Präsentation wird auf Zwischenfolien gezeigt und nicht auf jeder Folie.
• Die Gliederung der Präsentation wird in Anlehnung an Docker mit einem schwimmenden Wal visualisiert.
• Die Kosten und die Wirtschaftlichkeit des Projekts werden vorgestellt.
• Das Unternehmen wird mit einem Bild vorgestellt und nicht nur mit Text.
• Die verwendeten Bilder wurden selbst erstellt und passen perfekt zum Projekt.
• Die Projektphasen sind gut aufgeteilt und haben einen passenden Umfang.
• Die Projektphasen werden mit ihrer Dauer gut lesbar in Diagramm- und Textform dargestellt.
• Um die Zeit genau einzuhalten wurden Kommentare zur erwarteten Zeit in den Notizen verwendet.
• Das Projekt wurde testgetrieben entwickelt.
• Die Dokumentation der erstellten Anwendung wird im Detail vorgestellt. Alle erwarteten Dokumentationen (Benutzer und Entwickler) sind vorhanden.
• Die verwendeten Technologien (insb. Jakarta EE) werden gut verständlich erläutert.
• Es werden professionelle Werkzeuge zur statischen Codeanalyse (SonarQube) eingesetzt, die den Code objektiv bewerten.

Metadaten

• Titel der Projektarbeit: AO-Pflegerechner – Web-Anwendung für die Beratung in der Pflegezusatzversicherung
• Ausbildungsberuf: Fachinformatiker Anwendungsentwicklung
• Prüfung: Sommerprüfung 2020
• Bewertung: 100%
• IHK: IHK Oldenburg
• Name des Prüflings: Leon Brachwitz
  • Kontaktmöglichkeiten: Website, Facebook, Instagram, Twitter
• Ausbildungsbetrieb: ALTE OLDENBURGER Krankenversicherung AG
  • Kontaktmöglichkeiten: Website, Facebook, Instagram, Xing

Wenn du deine Projektarbeit auch auf dieser Seite veröffentlichen möchtest, dann sprich mich gerne an. Ich suche (sehr gute) Beispiele aus allen IT-Berufen.

Download

Vielen Dank an Leon Brachwitz und ALTE OLDENBURGER Krankenversicherung AG für das Bereitstellen der Projektpräsentation. Alle internen Angaben oder personenbezogenen Daten wurden entweder unkenntlich gemacht oder durch fiktive Werte ersetzt.

• Projektpräsentation Fachinformatiker Anwendungsentwicklung von Leon Brachwitz (IHK Oldenburg, Sommerprüfung 2020)
  

Weitere Infos zur Projektpräsentation

Du suchst noch mehr Tipps rund um die Projektpräsentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektpräsentation.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektpräsentation herunterladen.

Der Beitrag Projektpräsentation von Leon Brachwitz (mit 100% bewertet) erschien zuerst auf IT-Berufe-Podcast.