Um den Aufbau und den Ablauf der Abschlussprüfung in den IT-Berufen geht es in der einhundertachzigsten Episode des IT-Berufe-Pocasts.

Inhalt

Die Teile der Abschlussprüfung sollten allen Auszubildenden und Ausbilder:innen geläufig sein, da die drei Jahre der Ausbildung hauptsächlich auf diese Prüfung hinarbeiten.

Der Aufbau der Abschlussprüfung ist für alle IT-Berufe identisch, die Inhalte unterscheiden sich aber natürlich. Insbesondere die Dauer und die Inhalte der Projektarbeit sind berufsspezifisch.

Es gibt insgesamt 7 verschiedene IT-Berufe.

Fachinformatiker:in

Anwendungsentwicklung

Systemintegration

Daten- und Prozessanalyse

Digitale Vernetzung

IT-System-Elektroniker:in

Kauf­mann/Kauffrau für Digitalisierungsmanagement

Kaufmann/Kauffrau für IT-System-Management

Der Großteil (60%) der Inhalte der schriftlichen Prüfung (GAP Teil 1 und WiSo) ist für alle Berufe gleich.

Achtung: Die IHK-Prüfungen sind bundesweit einheitlich, aber in Baden-Württemberg laufen sie anders als in den übrigen 15 Bundesländern. Die folgenden Ausführungen gelten daher ggfs. nicht für Prüfungen in Baden-Württemberg.

Aufbau der Abschlussprüfung

Wer es ganz genau wissen will, schaut am besten in die jeweilige Berufsverordnung:

Fachinformatiker:in Anwendungsentwicklung

Fachinformatiker:in Systemintegration

Fachinformatiker:in Daten- und Prozessanalyse

Fachinformatiker:in Digitale Vernetzung

IT-System-Elektroniker:in

Kauf­mann/Kauffrau für Digitalisierungsmanagement

Kaufmann/Kauffrau für IT-System-Management

Die folgenden Zitate stammen aus der FIAusbV.

Teil 1 (der gestreckten Abschlussprüfung)

Teil 1 der gestreckten Abschlussprüfung findet im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes statt. Dieser Prüfungsteil ist für alle IT-Berufe identisch.

Im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes hat der Prüfling nachzuweisen, dass er in der Lage ist,

1. Kundenbedarfe zielgruppengerecht zu ermitteln,

2. Hard- und Software auszuwählen und ihre Beschaffung einzuleiten,

3. einen IT-Arbeitsplatz zu konfigurieren und zu testen und dabei die Bestimmungen und die betrieblichen Vorgaben zum Datenschutz, zur IT-Sicherheit und zur Qualitätssicherung einzuhalten,

4. Kunden und Kundinnen in die Nutzung des Arbeitsplatzes einzuweisen und

5. die Leistungserbringung zu kontrollieren und zu protokollieren.

(FIAusbV §9 Abs. 2)

Teil 1 der Prüfung ist eine schriftliche Prüfung über 90 Minuten, die nach 18 Monaten der Ausbildung absolviert werden muss. Inhalt sind alle im Ausbildungsrahmenplan (Teil der oben verlinkten Ausbildungsverordnung) und Rahmenlehrplan (für die Berufsschulen) bis zu diesem Zeitpunkt zu vermittelnden Inhalte.

Rahmenlehrplan für die Ausbildungsberufe Fachinformatiker und Fachinformatikerin sowie IT-System-Elektroniker und IT-System-Elektronikerin

Rahmenlehrplan für die Ausbildungsberufe Kaufmann für IT-System-Management, Kauffrau für IT-System-Management Kaufmann für Digitalisierungsmanagement sowie Kauffrau für Digitalisierungsmanagement

Das Ergebnis des ersten Prüfungsteils geht zu 20% in die Abschlussnote ein.

Tipps zur Vorbereitung auf die Prüfung gibt es in meinen entsprechenden Podcast-Episoden, z.B. Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe. Und hier habe ich eine große Liste mit allen potentiellen Prüfungsthemen für dich zusammengestellt: Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen.

Teil 2 (der gestreckten Abschlussprüfung)

In Teil 2 der Prüfung sollen die bereits in Teil 1 abgefragten Inhalte nicht explizit erneut abgefragt werden, sie werden aber als bekannt vorausgesetzt.

Teil 2 der Prüfung teilt sich in vier konkrete Prüfungsteile auf:

Projektarbeit

Zwei fachspezifische schriftliche Prüfungen

Wirtschaft- und Sozialkunde

Betriebliche Projektarbeit

Die betriebliche Projektarbeit ist in allen IT-Berufen durchzuführen. Sie unterscheidet sich aber je nach Beruf und Fachgebiet.

Um das beliebte Prüfungsthema RAID geht es in der einhundertneunundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

RAID: Redundant Array of Independent Disks (bzw. früher "inexpensive" statt "independent)

Idee: Mehrere Festplatten zu einem Verbund ("array") zusammenschließen

Ziel: Ausfallsicherheit und höhere Verfügbarkeit (durch Einführung von Redundanz)

Bei Ausfall einer Festplatte kann sie getauscht und das RAID-Array wiederhergestellt werden ("Rebuild"), in dieser Phase ist das RAID durch die hohe Belastung aber anfälliger für einen weiteren Festplattenausfall.

RAID ersetzt nicht die Datensicherung.

Lösung: Hardware- oder Software-RAID

Hardware mit speziellen RAID-Controllern

Software meist schon ins Betriebssystem eingebaut (z.B. in Linux)

Alternative: JBOD (just a bunch of disks)

Es gibt verschiedene RAID-Level

Kriterien: Mindestanzahl Festplatten, Ausfallwahrscheinlichkeit, maximal verkraftbare ausgefallene Festplatten, Lese-/Schreibgeschwindigkeit, Nettokapazität

RAID 0: Striping

keine Redundanz, Merksatz: "0 Redundanz", "0 Sicherheit"

mindestens 2 Festplatten nötig

teilt Festplatten in gleich große Blöcke auf und verteilt die Daten darauf (stripes)

Kapazität kann komplett genutzt werden

dadurch kann schneller gelesen werden, da von mehreren Festplatten parallel gelesen wird

auch das Schreiben geht schneller, da Daten parallel auf mehrere Festplatten geschrieben werden (aufgeteilt)

fällt eine Festplatte aus, ist der gesamte Verbund defekt

Ausfallwahrscheinlichkeit steigt, da Einzelwahrscheinlichkeiten multipliziert werden (z.B. bei 1% Ausfallwahrscheinlichkeit 2,97% gesamt)

Einsatz: Streaming (viel Lesen, wenig Schreiben, Datenverlust verkraftbar bzw. anderweitig abgesichert), mehrere kleine zu einem großen Datenträger zusammenbauen

Nachteil: hohe Ausfallwahrscheinlichkeit

RAID 1: Mirroring

komplette Redundanz, Merksatz: "1-zu-1-Kopie"

mindestens 2 Festplatten nötig

Daten werden auf allen Festplatten identisch abgelegt

Kapazität wird halbiert oder gedrittelt usw.

Lesegeschwindigkeit kann erhöht werden, indem Daten parallel von mehreren Festplatten gelesen werden

Schreiben dauert länger, weil Daten auf mehrere Platten geschrieben werden müssen (Redundanz)

Verbund fällt erst aus, wenn alle Festplatten ausfallen

Ausfallwahrscheinlichkeit sinkt deutlich, z.B. bei 1% je Platte auf 0,0001%

auch Mirroring ist keine Datensicherung, Viren werden sofort auf alle Platten geschrieben

Einsatz: Hochverfügbarkeitssysteme

Nachteil: geringe Nettokapazität

RAID 5: Paritäten

Teilredundanz durch Ablage von Paritätsinformationen

mindestens 3 Festplatten nötig

zusätzlich zu den auf mehrere Festplatten verteilten Daten werden auf allen Festplatten Paritätsinformationen (z.B. XOR) je Datenblock abgelegt

Kapazität wird reduziert (z.B. 2/3 bei drei Festplatten)

Lesegeschwindigkeit kann erhöht werden, indem Daten parallel von mehreren Festplatten gelesen werden

Schreiben dauert durch Berechnung der Parität länger

Verbund fällt erst aus, wenn zwei Festplatten defekt sind

Ausfallwahrscheinlichkeit sinkt, z.B. bei 1% je Platte auf 0,0298%

Nachteil: bei häufigen Schreibzugriffen durch Berechnung der Parität langsamer

Irrelevante RAID-Level

RAID 2: Striping mit Fehlerkorrektur, nur bei Großrechnern eingesetzt

RAID 3/4: wie RAID 5 nur mit dedizierter Paritätsfestplatte (die dadurch stark belastet und zum Flaschenhals wird), bei RAID 3 wird auf Byte-Ebene und bei RAID 4 auf Block-Ebene gestript

RAID 6: wie 5 nur mit doppelter Parität

Kombinationen von RAID-Levels

best of both worlds aus anderen RAID-Leveln

immer von links nach rechts lesen und im Diagramm von unten nach oben: 01 -> zuerst werden zwei RAID 0 erstellt und dann zu einem RAID 1 zusammengebaut

ein Leg ist das RAID-Array "unten" im Bild, aus dem das übergeordnete zusammengesetzt wird

es werden mind. 4 Festplatten benötigt

Kapazität wird halbiert

Verbund verträgt zwei Festplattenausfälle, aber es ist wichtig, welche Platten ausfallen

RAID 01

Um das beliebte Prüfungsthema Datensicherung geht es in der einhundertachtundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Datensicherung ist quasi das deutsche Wort für Backup und behandelt das Sichern und Wiederherstellen von Daten auf Sicherungsmedien wie Magnetbändern, externen Festplatten oder der Cloud. Es geht hierbei um den Schutz vor Datenverlust.

Abgrenzung von Datensicherung, Datensicherheit und Datenschutz. Siehe auch Datenschutz vs. Datensicherheit vs. Datensicherung.

Die Datensicherung ist ein Teil der Datensicherheit, der sich um das Schutzziel Verfügbarkeit kümmert.

Warum können Daten verloren gehen?

Hardwaredefekte, Probleme im Stromnetz, Feuer/Wasser, Naturkatastrophen, menschliches Versagen oder Vorsatz (z.B. absichtliches Löschen oder Diebstahl), Ransomware

Ein Datenverlust kann für Unternehmen (aber auch Privatpersonen) große negative Auswirkungen haben. In schlimmen Fällen kann das Unternehmen nicht weiter arbeiten und muss Insolvenz anmelden.

Mitarbeiter sollten zum Thema Datenverlust sensibilisiert werden.

Was sind die Konsequenzen eines Datenverlustes für das Unternehmen und die Person selbst?

Dateien sofort abspeichern und nicht erst nach stundenlanger Arbeit.

Dateien regelmäßig speichern.

Nicht nur auf der eigenen Festplatte speichern, sondern im Netzwerk.

Was sind sicherungswürdige Daten?

Daten, die man nicht ohne Weiteres wiederbeschaffen kann (z.B. selbst erstellte Dateien, Fotos, Dokumente, Arbeitsergebnisse).

Meist werden Betriebssystemdaten und Programminstallationen nicht gesichert.

Grundsätzlich kommt es darauf an, wie schnell Daten wiederhergestellt werden können müssen. Auch das Betriebssystem kann daher gesichert werden müssen, wenn eine Neuinstallation zu lange dauern würde.

Es gibt auch gesetzliche Aufbewahrungsfristen für Daten, aber bitte nicht mit Archivierung durcheinanderbringen.

Wichtig bei der Datensicherung: auch die Datenwiederherstellung testen!

Wie erkennt die Software, welche Daten zu sichern sind?

Metadaten wie letztes Änderungsdatum, Archiv-Flag oder Dateihash.

Wie viele Daten werden gesichert und wie lange dauert die Wiederherstellung?

Trade Off zwischen geringem Speicherverbrauch bzw. langer Backuplaufzeit und schneller Wiederherstellungsdauer.

Unterschiedliche Verfahren: Vollbackup (alle Daten sichern), differenzielles Backup (nur geänderte Daten zum letzten Vollbackup werden gesichert) und inkrementelles Backup (geänderte Daten zum letzten Voll- oder inkrementellen Backup werden gesichert).

Vollbackup: Viel Speicherverbrauch, lange Backuplaufzeit, schnelle Wiederherstellung (nur 1 Backup nötig).

Differenzielles Backup: Mittelweg zwischen Speicherverbrauch/Backuplaufzeit und Wiederherstellung (2 Backups nötig).

Inkrementelles Backup: Geringster Speicherverbrauch, aber längste Wiederherstellung (z.B. 5 Backups nötig).

Backup-Medien

Kriterien bei der Auswahl von Backupmedien: Kapazität, Transferrate, Zugriffsgeschwindigkeit, Kosten, Lebensdauer, Störanfälligkeit

Mögliche Medien: Magnetbänder, Festplatten/HDDs, SSDs, USB-Sticks, CDs/DVDs/BluRays, Cloud

Generationenprinzip bzw. Großvater/Vater/Sohn

Auch Backup-Medien können kaputt gehen! Nur ein einziges Medium zu nutzen, ist daher nicht zu empfehlen.

Außerdem würden neue Sicherungen die alten überschreiben, enthalten aber ggfs. früher gelöschte Daten nicht mehr für eine spätere Wiederherstellung.

Zu viele Medien kosten aber unverhältnismäßig viel Geld. Daher ist ein Mittelweg nötig: ein Rotationsprinzip.

"Übliche" Medien bei 5-Tage-Woche: 4 x Sohn (Mo - Do), 4 x Vater (Fr), 12 x Großvater (Monat)

Hot/Cold Backup

Cold-Backup: Herunterfahren der zu sichernden Systeme nötig. Einfach, aber mit Downtime verbunden.

Hot-Backup: Systeme werden während des Betriebs gesichert. Schwierig (z.B. Redo-Logs bei Datenbanken), aber keine Downtime nötig.

Mein privates Backup-Konzept

Nur eigene Dateien sichern, keine Betriebssystemdaten oder Programme.

Einen Rückblick auf die Fachgespräche (Fachinformatiker:in Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung im Sommer 2022 gibt es in der einhundertsiebenundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Fachgespräche Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung)

Disclaimer: Meine Erfahrungen aus den Prüfungen, an denen ich beteiligt war, ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland.

Viele der genannten Themen für das Fachgespräch gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben (insb. die wirtschaftlichen Themen).

Fast immer falsch beantwortet wurden Fragen nach Stundensatz, laufenden Kosten, Lösch-Anomalie, Lambda-Ausdrücken, generischen Klassen.

Häufige Fragen im Fachgespräch

Das hier ist meine Liste mit den häufigsten Fragen im Fachgespräch für Fachinformatiker:innen Anwendungsentwicklung, absteigend nach Anzahl sortiert.

Man erkennt deutlich, dass unter der Top-Themen sehr viele Wirtschaftsthemen sind, weil viele "Techniker:innen" diesen Bereich bei der Prüfungsvorbereitung vernachlässigen und dementsprechend in Projektdokumentation und Projektpräsentation falsch machen, was dann entsprechende Fragen im Fachgespräch provoziert.

Viele der anderen Themen ergeben sich aus Technologien, die die Prüflinge selbst eingesetzt haben. Ich sage immer wieder: Alles, was man benutzt (oder in der Projektpräsentation erwähnt), muss man auch erklären können. Da viele Projekte aktuell als Single-Page-Application in JavaScript mit einer anderen Programmiersprache im Backend (z.B. Java) umgesetzt werden, kommen z.B. Fragen nach REST, OAuth, Typisierung und JavaScript-Spefizika immer öfter vor.

Stundensatz (15)

Fast immer falsch berechnet (nur Brutto-Ausbildungsvergütung enthalten).

Normalisierung (13)

Oft nicht sauber mit Fachbegriffen erklärt.

Sozialversicherung (13)

Viele kennen den Arbeitgeberanteil nicht.

Kapselung (11)

Getter/Setter, Sichtbarkeitsmodifizierer usw.

Klasse vs. Objekt (11)

"Ein Objekt ist ein Teil einer Klasse" usw.

Lambda-Ausdrücke (11)

Werden ständig genutzt, aber nur sehr wenige Prüflinge können sie erklären.

Vererbung (10)

Wir insb. in Frameworks häufig benötigt, aber zu den Details fehlen häufig Kenntnisse.

Anomalien (Einfüge-/Änderungs-/Löschanomalie) (9)

Die Löschanomalie wurde dieses Jahr nicht einmal korrekt erklärt.

Einzel- vs. Gemeinkosten (9)

Viele Prüflinge haben offensichtlich noch nie etwas von einem Kostenträger gehört.

Polymorphie (9)

Viele Prüflinge werfen das mit Vererbung durcheinander und können es nicht sauber abgrenzen.

Kardinalitäten (8)

Dieses Thema haben die meisten Prüflinge gut beantwortet, aber teilweise mit seltsamen Beispielen.

Typisierung (8)

Die wenigsten Prüflinge können statisch/dynamisch und vor allem stark/schwach abgrenzen.

Generische Klassen (7)

Sauber erklären können das die wenigsten Prüflinge.

OAuth (6)

REST-APIs werden heute offensichtlich ohne jegliche Absicherung erstellt.

Softwarequalität (6)

Die gute alte (und neue) ISO-Norm ist nur wenigen Prüflingen bekannt.

fixe vs. variable Kosten (5)

Sie werden oft mit Einzel-/Gemeinkosten verwechselt.

Hashverfahren (5)

Die Eigenschaften eines guten Hashverfahrens können die wenigsten Prüflinge nennen, wissen aber wenigstens, wofür man sie braucht.

laufende Kosten (5)

In vielen Projekten gibt es keine (!) laufenden Kosten.

Lohn vs. Gehalt (5)

Und natürlich darf auch die Ausbildungsvergütung nicht fehlen!

MVC/MVVM/MVP usw. (5)

Die Architektur der eigenen Anwendung sollte man erklären und auch von Alternativen abgrenzen können.

Redundanzen (5)

Der Feind jedes Datenbankmodellierers. Wird häufig richtig erklärt.

REST (5)

Jeder nutzt es, kaum jemand kann es korrekt erklären.

Scrum (5)

Quasi Grundwissen für alle IT-Berufe.

Betriebsabrechnungsbogen (4)

Oft eine Anschlussfrage bei Einzel-/Gemeinkosten.

Lastenheft/Pflichtenheft (4)

Einen Rückblick auf die Projektpräsentationen (Fachinformatiker:in Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung im Sommer 2022 gibt es in der einhundertsechsundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Projektpräsentationen Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung)

Disclaimer: Meine Meinung ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland.

Ich schaue insbesondere auf die Gestaltung der Folien und den Vortrag, aber wichtig sind natürlich auch die fachlichen/technischen Inhalte der Präsentation.

Einzelne Punkte auf der folgenden Liste führen nicht zwangsläufig zu Punktabzug bei der Note, aber oft treten mehrere Punkte gemeinsam auf, was dann einen Punktabzug rechtfertigt.

Viele "Probleme" mit den Projektpräsentationen gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben.

Foliengestaltung und Vortrag

Oft wurden Punktlisten nicht Schritt-für-Schritt eingeblendet, sondern sofort als Ganzes gezeigt.

(Unnötige) Kopfzeile in einer Präsentation war winzig klein.

Cliparts für die Darstellung des Ist-Zustands, anstatt eigene Fotos zu machen.

Präsentationen vom selben Unternehmen sahen fast identisch aus und hatten auch einen sehr ähnlichen Aufbau.

Der Text auf den Folien war oft sehr klein und kaum lesbar.

(Offensichtliche) Rechtschreibfehler auf den Folien.

Tortendiagramme sahen in fast allen Präsentationen identisch aus (Standardfarben von PowerPoint genutzt).

Vorstellung des Prüflings: graue Silhouette statt Bild verwendet.

Präsentation mit LaTeX erstellt, aber leider ausschließlich Textfolien.

Code wurde durch Zeigen an der Leinwand erklärt, anstatt ihn visuell hervorzuheben.

Prüfling kommentierte die Vorstellung des Unternehmens mit "hier habe ich mal statt des klassischen Bildes unsere Azubis genommen".

Ein Prüfling hat die Architektur seiner Anwendung an die Tafel gezeichnet.

Einige Prüflinge haben stark abgelesen und kaum Blickkontakt zum Prüfungsausschuss gehabt.

Fehlende/unnötige Inhalte

Oft wurden die Artefakte aus der Projektdokumentation nicht in der Projektpräsentation gezeigt.

Oft werden Inhalte genannt, aber nicht visualisiert (z.B. 3-Schichten-Architektur ohne Grafik).

Angeblich erstellte Artefakte werden erwähnt, aber nicht gezeigt.

Teilweise wurde viel zu detailliert auf Code eingegangen.

Das Ziel des Projekts wird oft nicht deutlich.

Jedes genutzt JavaScript-Package wurde inkl. Versionsnummer aufgeführt und erklärt.

Ein Prüfling hat jede verwendete Technologie ausführlich erklärt (z.B. Kafka und Kubernetes).

Scrum wurde in einer Präsentation ausführlich erklärt.

Sonstiges

Notepad++ als IDE verwendet.

Deployment als Upload auf einen FTP-Server.

Einige Prüflinge haben den Prüfungsausschuss geduzt.

Prüfling mit Mac hatte keinen Adapter für HDMI dabei.

Prüfling hat einen Programmablaufplan erstellt, anstatt ein UML-Diagramm zu nutzen.

Einige Unternehmen entwickeln wohl auf Englisch, aber niemand schaut auf die korrekten Vokabeln.

Mögliche/erwartete Artefakte

Die folgenden Artefakte sind in einer Projektpräsentation möglich bzw. ich würde sie in einer "sehr guten" Arbeit erwarten. Auch hier gilt: Wenn mal eines oder mehrere der Artefakte fehlen, heißt das nicht automatisch, dass eine schlechte Note folgt. Es geht immer auch um den Gesamteindruck der Präsentation inkl. Gestik, Mimik usw.

Projektplanung: Zeitplanung, Ressourcen, Entwicklungsprozess, Kosten, Amortisation

Ziel des Projekts: Use-Case-Diagramm, Aktivitätsdiagramm, Lasten-/Pflichtenheft, ereignisgesteuerte Prozesskette

Architektur: Komponentendiagramm

Technologien: Programmiersprache, Frameworks

Implementierung: Source Code, Klassendiagramm, Sequenzdiagramm

Datenmodellierung: Entity-Relationship-Modell, Tabellenmodell

Test: Source Code, Testprotokoll

User Interface: Mockups

Qualitätssicherung: Code-Reviews, Entwicklungsprozess, statische Codeanalyse, CI/CD

Dokumentation: Entwickler-/Kundendokumentation

Einen Rückblick auf die Projektdokumentationen (Fachinformatiker:in Anwendungsentwicklung) zu Teil 2 der gestreckten Abschlussprüfung im Sommer 2022 gibt es in der einhundertfünfundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Projektdokumentationen Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung)

Disclaimer: Meine Meinung ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland.

Ich schaue oft auch auf die formellen Details, aber wichtiger sind natürlich immer die fachlichen/technischen Inhalte.

Einzelne Punkte auf der folgenden Liste führen nicht zwangsläufig zu Punktabzug bei der Note, aber oft treten mehrere Punkte gemeinsam auf, was dann einen Punktabzug rechtfertigt.

Viele "Probleme" mit den Projektdokumentationen gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben.

Allgemeines

Messaging wird in mehreren Projekten eingesetzt.

Nur wenige Use-Case-Diagramme gesehen. -> Was macht das System eigentlich?

Oft wurde ein Tabellenmodell ER-Modell genannt.

Frameworks oder gar Programmiersprachen waren vor der Projektdurchführung nicht bekannt.

Formalia

Abbildungen wurden mit ihrem Namen referenziert, anstatt mit der Seitenzahl.

Einige Dokumentationen waren im Flattersatz gesetzt.

Eine Dokumentation hatte 5 (!) Ebenen im Inhaltsverzeichnis, also z.B. bis Kapitel 4.2.4.1.2.

Ein Kapitel bestand nur aus einem (!) Aufzählungspunkt.

"Textmarke nicht definiert" im Dokument.

Stundensatzberechnung

Es wurden verschiedene Stundensätze für einzelne Mitarbeiter angegeben, dann aber nur mit einem einheitlichen gerechnet.

Der Stundensatz wurde oft nur aus der Azubivergütung berechnet (z.B. Vergütung / 20 / 8 -> 6 EUR/h).

Ein Prüfling hat explizit geschrieben, dass der Stundensatz sich nur aus der Azubivergütung berechnet, setzt dann aber 75 EUR/h an.

Oft wird der Datenschutz als Begründung genutzt, die echten Stundensätze nicht nennen zu können.

Kosten

Es wurden 500 EUR/Monat als laufende Kosten für einen (!) Server angesetzt.

Die Abnahme wurde mit 3h eingeplant, aber nur mit 1h in den Kosten aufgeführt.

Stunden des Fachbereichs tauchten nicht in den Kosten auf.

Ein Prüfling hat die Stunden anderer Mitarbeiter mit in seine 70h aufsummiert.

Begründung von Entscheidungen

Begründung für technische Entscheidung: "Ich soll das so machen."

Ein Prüfling hat durchgängig geschrieben, dass "man" das Projekt umgesetzt hat.

Es gab eine Nutzwertanalyse, bei der die Eigenentwicklung in allen (!) Kriterien die maximale Punktzahl hatte.

Anforderungsermittlung

Im Lastenheft wurde vom Kunden angeblich Java 11 und Messaging gefordert.

Ein Lastenheft bestand nur aus zwei Sätzen und das dazu passende Pflichtenheft war "nicht nötig".

Die Programmiersprache wurde in einer gesamten Dokumentation nicht genannt.

Fehlende oder überflüssige Inhalte

Eine Dokumentation enthielt keinerlei Zeitplanung, Phasen oder Prozess.

Die Qualitätssicherung fehlt oft komplett (z.B. Testen, CI/CD, Reviews).

Auf 1/2 Seite wurde Scrum im Detail erklärt bzw. auf einer ganzen Seite REST.

Sonstiges

Ein Prüfling hat sich eigene Diagrammformen ausgedacht, anstatt einfach UML zu nutzen.

Beim Soll-Ist-Vergleich wurde Soll - Ist gerechnet.

Security wurde bei SSH absichtlich ausgeschaltet.

In einer Detailplanung war ein Block 23h lang.

Es wurde mit einer Low-Code-Plattform gearbeitet, für die es eigentlich nichts zu programmieren gab.

REST wird inzwischen sehr oft verwendet, aber die wenigsten Prüflinge wissen, wie man die APIs absichert.

REST-APIs sehen oft sehr seltsam aus ("GetById" im Path).

Positiv aufgefallen

Das Code-Review hat tatsächlich auch mögliche Optimierungen ergeben (Namen, Struktur).

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Datenbankmodellierung (Lernzielkontrolle zum relationalen Tabellenmodell)

Datenbankmodellierung (Lernzielkontrolle zum Entity-Relationship-Modell)

Welche Programmiersprache du für dein Abschlussprojekt verwenden solltest

Einen kurzen Rückblick auf Teil 1 der gestreckten Abschlussprüfung im Frühjahr 2022 gibt es in der einhundertvierundsiebzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Die Aufgaben

Aufgabe 1: So noch nie gesehen!

Präsentationen erstellen: Folien und Notizen formulieren

Schlagworte erklären: u.a. Big Data, Industrie 4.0, DSGVO

Inhalte für ein Angebot begründen

Aufgabe 2: Sehr hardwarelastig mit vielen Bildern!

Einbau einer CPU erklären

Wärmeleitpaste erläutern

RAM im Dual Channel betreiben

SSD SATA und M.2 unterscheiden

Grafikanschlüsse benennen

USB-C vs. USB-A

Erklären: logische Prozessoren, Cache

GHz in Hertz umrechnen

Aufgabe 3: Netzwerkanalyse aus der Praxis.

Wie kommt der Laptop ins WLAN?

WPA-PSK vs. RADIUS

ISO/OSI rauf und runter

Infos aus Screenshot Schicht 1 zuordnen

MAC und Local IPv6 erklären

DHCP erkennen

Netz-/Host-/Broadcast-Adresse ermitteln

Fehler benennen

Aufgabe 4: Ein bisschen (!) was für Anwendungsentwickler:innen.

Workspace-Management-Software

Cloud vs. On-Premises

Eigenfertigung vs. Lizenzen berechnen

Struktogramm befüllen

Uploaddauer berechnen

Meine "Highlights"

RADIUS != Radius (halber Kreisdurchmesser)

DHCP vs. DNS (oft durcheinander gebracht)

Subnetting konnten fast alle

Tipps für zukünftige Prüfungen

Standardinhalte anschauen (ISO/OSI, Algorithmen)

Hardware und Netzwerktechnik wurde recht tiefgehend, aber auch praxisbezogen abgefragt

Alle Seiten der Prüfung anschauen und nicht beim Konzeptpapier aufhören

Aufgaben komplett lesen und alle Fragestellungen analog den Formulierungen beantworten

nicht nur Theorie, sondern auch Praxis lernen (ipconfig etc.)

alle Abkürzungen lernen (z.B. DHCP, RADIUS, DNS)

Vorsilben wie Giga und Mega lernen und von Gibi und Mibi abgrenzen

Ergebnis

schlechtes Ergebnis, schlechter Schnitt, kaum sehr gute Noten

FISI und FIAE sehr ähnlich abgeschnitten

FISI: Aufgabe 4 schlecht, FIAE: Aufgabe 3 schlecht

Aufgabe 3 am schlechtesten insgesamt

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Das ISO/OSI-Modell (Teil 1) (erster Teil der Serie)

URLs (Netzwerkgrundlagen) (erster Teil der Serie)

Cloud Computing Teil 1 (On Premise und Virtuelle Maschinen) (erster Teil der Serie)

Heute habe ich zwei Stellenangebote in Vechta für dich.

Mein Arbeitgeber, die ALTE OLDENBURGER Krankenversicherung AG aus Vechta, sucht mal wieder Verstärkung im IT-Bereich. Aktuell sind wir auf der Suche nach Softwareentwickler:innen und Systemadministrator:innen. Schau gerne mal vorbei, falls du auf der Suche nach einer neuen Herausforderung bist:

* Softwareentwickler (m/w/d)

* Entwicklung von versicherungstechnischen Anwendungen in einer modernen IT-Infrastruktur

* Systemadministrator (m/w/d)

* Administration einer modernen mit VMWare und Citrix virtualisierten Microsoft- und Linux-Infrastruktur

Hier kommen ein paar allgemeine Rahmendaten zur Arbeit bei uns, die für beide Stellen gelten:

* Art der Anstellung: unbefristete Festanstellung

* Arbeitsort: ALTE OLDENBURGER Krankenversicherung AG, Alte-Oldenburger-Platz 1, 49377 Vechta

* Beginn: schnellstmöglich

* Sonderleistungen: Urlaubs- und Weihnachtsgeld (13,3 Gehälter), Fahrtkostenzuschuss, 40 Euro vermögenswirksame Leistungen, Firmenfitness, Mitarbeiterrabatte für Versicherungen, betriebliche Altersvorsorge, Kinderbetreuungszuschuss

* Wöchentliche Arbeitszeit: 38 Stunden im Gleitzeitmodell ohne Kernarbeitszeit (bei einer Vollzeitbeschäftigung)

* Homeoffice: Möglichkeit zur Tätigkeit im Homeoffice (bis zu 60 %)

* Jährlicher Urlaubsanspruch: 30 Tage

* zusätzlicher Urlaub: Möglichkeit zur Umwandlung eines Teils des Urlaubsgelds in 5 Tage zusätzlichen Urlaub

* Weiterbildungsmöglichkeiten: (Duales) Studium (z.B. Wirtschaftsinformatik, technische Informatik), IHK-Weiterbildungen, externe Technologieschulungen, Konferenzbesuche

* Sonstiges: frisches Obst, kostenlose Kaffeespezialitäten, modern und ergonomisch ausgestattete Arbeitsplätze, betriebliche Gesundheitsförderung, ein hervorragendes Betriebsrestaurant mit bezuschussten Speisen, ein Employee-Assistance-Program, viele gemeinsame Aktivitäten wie z.B. Weihnachtsfeier, Betriebsausflug oder Spargelessen

Wir freuen uns auf deine Bewerbung! Vielleicht sind wir dann ja bald Kolleg:innen! 😊

Links

* Permalink zu dieser Podcast-Episode

* RSS-Feed des Podcasts

* Softwareentwickler (m/w/d)

* Systemadministrator (m/w/d)

Mit einer kleinen Spendenaktion möchte ich den Menschen in der Ukraine helfen.

Die Bilder, die uns vom Krieg in der Ukraine erreichen, machen mich fassungslos. Viele Menschen sind auf der Flucht vor der sinnlosen Zerstörung. Und insb. die Menschen, die in ihrem Heimatland zurückbleiben, brauchen Hilfe.

Ich möchte helfen! Daher spende ich 50% der Einnahmen meiner Produktverkäufe der kommenden Woche an die Aktion Deutschland Hilft über das Spendenkonto Nothilfe.

Damit du auch etwas davon hast, habe ich den Gutscheincode „UKRAINE“ eingerichtet, mit dem du 30% Rabatt auf alle meine Produkte bekommst.

Die folgenden Links führen dich direkt zu den Produkten und enthalten bereits den Rabattcode. Die Aktion läuft bis zum 13.03.2022 um 23:59 Uhr.

* Datenbanken und Datenmodellierung (Hörbuch): 13,99 EUR (statt 19,99 EUR), davon 7 EUR Spende

* Programmierung und Objektorientierung (Hörbuch): 13,99 EUR (statt 19,99 EUR), davon 7 EUR Spende

* Hörbuch-Bundle (Datenbanken/Programmierung): 20,99 EUR (statt 29,99 EUR), davon 11 EUR Spende

* Vorlage zur Projektdokumentation der IT-Berufe (Basic): 17,49 EUR (statt 24,99 EUR), davon 9 EUR Spende

* Vorlage zur Projektdokumentation der IT-Berufe (Premium): 27,99 EUR (statt 39,99 EUR), davon 14 EUR Spende

* Prüfungsbundle: Dokumentationsvorlage und Hörbucher: 34,99 EUR (statt 49,99 EUR), davon 18 EUR Spende

Ich werde im nächsten Newsletter über den Ausgang der Spendenaktion informieren. Ich hoffe, es kommen ein paar Euro zusammen.

Zur Aktion Deutschland Hilft:

Im Namen von 23 deutschen Hilfsorganisationen rufen Bündnis Entwicklung Hilft und Aktion Deutschland Hilft gemeinsam zu Spenden auf, um den Menschen bei der Bewältigung von Katastrophen zu helfen. Wir garantieren Ihnen, dass die Spendengelder gemäß des DZI Spenden-Siegels eingesetzt werden.

Links

* Permalink zu dieser Podcast-Episode

* RSS-Feed des Podcasts

* Spendenkonto Nothilfe

Um die Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung (GAP) der IT-Berufe im Bereich Projektmanagement geht es in der einhundertdreiundsiebzigsten Episode des IT-Berufe-Podcasts.

Planen, Vorbereiten und Durchführen von Arbeitsaufgaben in Abstimmung mit den kundenspezifischen Geschäfts- und Leistungsprozessen

Nachtrag zu Teil 1:

Change Management (Prozess zur Umsetzung von Veränderungen in Unternehmen) z.B. nach Lewin (Unfreeze, Change, Refreeze)

Kaizen, Continuous Improvement

1e: Probleme analysieren und als Aufgabe definieren sowie Lösungsalternativen entwickeln und beurteilen

Analysieren im Sinne von Erkennen und Einordnen

Problemlösungsvarianten entwickeln

Probleme beseitigen durch, z.B.:

Situationsanalyse

Problemeingrenzung

Aufzeigen von Alternativen

Auswahl von Lösungen

Analysieren der Chancen und Risiken der ausgewählten Lösung anhand vorher definierter Beurteilungskriterien

Root-Cause-Analysis

5 Whys

1f: Arbeits- und Organisationsmittel wirtschaftlich und ökologisch unter Berücksichtigung der vorhandenen Ressourcen und der Budgetvorgaben einsetzen

Berücksichtigung der Formen von Arbeitsorganisation, z.B.:

Gruppenarbeit

Pair Programming

Budgetplanung als Teil der Unternehmensplanung

effektiver und effizienter Einsatz von Arbeits- und Organisationsmitteln

Prüfung des Ressourceneinsatzes auf:

rechtliche Zulässigkeit

technische und organisatorische Machbarkeit

ökologische Nachhaltigkeit und Wirtschaftlichkeit

Prüfung der Wirtschaftlichkeit mittels betriebswirtschaftlicher Methoden, z.B.:

Rentabilitätsrechnung

Amortisationsrechnung

Machbarkeitsanalyse: technisch, organisatorisch, wirtschaftlich, zeitlich, rechtlich

Make-or-buy-Entscheidung

Effektivität: Die richtigen Dinge tun. Effizienz: Die Dinge richtig tun.

Budget: die für einen bestimmten Zweck zur Verfügung stehenden Geldmittel

Umsatz: Absatzmenge * Verkaufspreis

Gewinn: Erlöse - Kosten

Deckungsbeitrag: Stückpreis - variable Stückkosten

Rentabilität: Gewinn / Kapital

Amortisation: Investition / Ertrag pro Jahr

1g: Aufgaben im Team sowie mit internen und externen Kunden und Kundinnen planen und abstimmen

Team als soziales Gefüge verstehen ("social awareness")

Phasen der Teamentwicklung kennen und anwenden (Konflikt, Kontrakt, Kooperation)

Methoden des sachbezogenen Verhandelns kennen und anwenden, z.B.:

Win-win-Strategie

Harvard-Konzept

adressatengerechte Kommunikation

Prozess der Teambildung nach Bruce Tuckman: Forming, Storming, Norming, Performing, (Adjourning)

Win-win: Konfliktlösung ohne Verlierer

Harvard-Konzept

Menschen und Interessen trennen

Fokus auf Interessen und nicht auf Positionen

Entscheidungsoptionen entwickeln

objektive Beurteilungskriterien anwenden

BATNA: Best Alternative To a Negotiated Agreement

Communication is what the listener does (Peter Drucker)

1h: betriebswirtschaftlich relevante Daten erheben und bewerten und dabei Geschäfts- und Leistungsprozesse berücksichtigen

Bewerten anhand vorgegebener unternehmensspezifischer Daten

1i: eigene Vorgehensweise sowie die Aufgabendurchführung im Team reflektieren und bei der Verbesserung der Arbeitsprozesse mitwirken

gemeinsame kritische Analyse der bisherigen Zusammenarbeit und der Ergebnisse ("lessons learnt")

offenes Ansprechen von Erfolgen und Problemen

gemeinsame Entwicklung von Maßnahmen zur Verbesserung, z.B. SCRUM-Retrospektive

konstruktive Kritik

Retrospektive: Wie kann der Prozess und die Zusammenarbeit im Team verbessert werden?

konstruktive Kritik: konkrete Wahrnehmung schildern (nicht interpretieren, nicht verallgemeinern), Auswirkungen aufzeigen, Ich-Botschaft senden, Wunsch äußern

Literaturempfehlungen

Das hier ist die "Handreichung", von der ich im Podcast spreche:

*

*

*

*

*

Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

7 Change Management Methoden, die du kennen solltest

Mein Projekt amortisiert sich nicht

Anforderungsermittlung (nicht nur für dein Abschlussprojekt)