IT-Berufe-Podcast Archiv

Um den sinnvollen Aufbau eines IHK-Abschlussprojekts für Fachinformatiker:innen Anwendungsentwicklung geht es in der einhundertfünfundachzigsten Episode des IT-Berufe-Podcasts. TL;DR Für dein Abschlussprojekt als Fachinformatiker:in Anwendungsentwicklung empfehle ich das Wasserfallmodell, weil du deine eigene Prüfungsleistung innerhalb von 80 Stunden umsetzt und die Anforderungen früh klären kannst. Wenn du Diagramme und andere Artefakte passend zum Projektablauf erstellst, helfen sie dir beim Entwickeln und machen deine Entscheidungen für Prüfer:innen nachvollziehbar. Aus den fachlichen Anforderungen entstehen ein abgestimmter Lösungsentwurf und das Pflichtenheft, auf deren Grundlage du programmierst, die Qualität prüfst und die Software zielgruppengerecht dokumentierst. Kapitelmarken [00:00:00] Ein Abschlussprojekt mit nachvollziehbarem Aufbau [00:03:54] Softwareentwicklung und weitere Pflichtbestandteile [00:05:13] Das Vorgehensmodell selbst wählen und begründen [00:08:23] Scrum im kurzen Einzelprojekt [00:13:45] Extreme Programming und Kanban im Prüfungsrahmen [00:16:50] Meine Empfehlung für das Wasserfallmodell [00:17:08] Artefakte als Belege für methodisches Entwickeln [00:19:25] Softwareentwicklung im Zusammenhang mit KI [00:21:04] Den Zweck von Artefakten deutlich machen [00:24:18] Vorab modellieren und nachträglich dokumentieren [00:28:13] Artefakte passend zur Methode und Reihenfolge einsetzen [00:31:28] Vom abgestimmten Mockup zum Datenmodell [00:35:34] Den bisherigen Zustand untersuchen [00:37:58] Anforderungen erfassen und strukturieren [00:39:38] Anwendungsfälle mit einem Use-Case-Diagramm abstimmen [00:41:50] Den künftigen Prozess entwerfen [00:44:51] Die Plattform auswählen und begründen [00:46:21] Oberfläche und externe Schnittstellen skizzieren [00:49:23] Ein unabhängiges ER-Modell ableiten [00:52:06] Architektur und Komponenten planen [00:54:51] Fachbegriffe im Glossar festhalten [00:56:15] Datenhaltung festlegen [00:58:24] Programmiersprache und Framework auswählen [01:00:39] Geschäftslogik und Domäne entwerfen [01:04:27] Build und Deployment vorbereiten [01:10:15] Qualitätskriterien und Tests planen [01:13:45] Technische Entscheidungen im Pflichtenheft festhalten [01:15:55] Mit TDD programmieren und das Datenbankvorgehen wählen [01:18:25] Code und Ergebnisse im Anhang zeigen [01:20:11] Die Anwendung auf der Zielumgebung bereitstellen [01:21:36] Tests ausführen und Qualität belegen [01:23:35] Die Software zielgruppengerecht dokumentieren [01:27:18] Beispielprojekt: Eine Excel-Lösung ablösen [01:27:59] Beispiel: Den alten Ablauf und Anforderungen erfassen [01:30:19] Beispiel: Neuen Prozess und Mockups entwerfen [01:32:21] Beispiel: Datenmodell und Architektur ableiten [01:33:34] Beispiel: Datenbank und vertraute Technologien wählen [01:34:37] Beispiel: Geschäftslogik und Build vorbereiten [01:36:36] Beispiel: Qualität planen und Pflichtenheft erstellen [01:38:42] Beispiel: Mit TDD entwickeln und deployen [01:40:08] Beispiel: Dokumente erzeugen und Belege auswählen [01:42:35] Frühzeitiges Feedback im Fachbereich einholen [01:43:56] Newsletter und Shownotes Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung Oft lese ich Projektdokumentationen für den Beruf Fachinformatiker:in Anwendungsentwicklung, die in sich einfach nicht stimmig sind. Der Projektablauf folgt keinem roten Faden und Artefakte werden wild durcheinandergewürfelt. Oft werden auch einfach nur Kapitel aus Dokumentationsvorlagen "ausgefüllt", scheinbar ohne über ihre Sinnhaftigkeit nachzudenken. In dieser Podcast-Episode gebe ich einen Überblick über einen - aus meiner Sicht - sinnvollen Ablauf eines IHK-Projekts im Bereich Anwendungsentwicklung inkl. möglicher Artefakte und ihrem Zweck. Dabei gehe ich nicht auf die Beschreibung des Projekts, die Wirtschaftlichkeitsbetrachtung, das Projektmanagement, die Ressourcenplanung usw. ein, sondern nur auf die Planung und Durchführung der eigentlichen Aufgabe: der Entwicklung einer Softwarelösung. Selbstverständlich gehören aber alle genannten Punkte auch in eine IHK-Projektdokumentation. Wahl des Vorgehensmodells Fast immer ist das Wasserfallmodell das einzig sinnvolle Vorgehensmodell, da das IHK-Projekt vom Prüfling alleine in einer fest vorgegebenen Zeit mit vorgegebenem (weil im Antrag genehmigten) Umfang umgesetzt werden muss. Praxisbeispiele für unpassende Prozesse: Scrum gewählt, aber klassische Wasserfallphasen durchgeführt/beschrieben Lasten-/Pflichtenheft erstellt statt User Stories Projekt alleine umgesetzt ohne Team/Scrum Master/Product Owner gesamtes Projekt ist ein einziger Sprint XP gewählt, aber keine Praktiken (z.B. Pair Programming, Test Driven Development) angewendet Kanban gewählt, aber Lanes nur ToDo/Doing/Done Artefakte methodisch sinnvoll einsetzen Software soll nicht einfach "runterprogrammiert" werden, sondern methodisch entwickelt werden. Dabei helfen verschiedene Artefakte wie Entity-Relationship-Modelle, UML-Diagramme usw. Diagramme können oft auf zwei Arten eingesetzt werden: zur Modellierung (vor der Implementierung) und zur Dokumentation (nach der Implementierung). Sie haben keinen Selbstzweck, sondern sollen immer den jeweiligen Prozessschritt unterstützen. Ihr Einsatz muss zum gewählten Prozess passen. Ein Klassendiagramm zur Modellierung passt z.B. nicht so gut zu Test-Driven-Development, bei dem die Klassen sich erst bei der Implementierung ergeben. Die Artefakte müssen auch zeitlich sinnvoll im Projekt untergebracht werden. Die Anforderungen erst nach der Implementierung zu dokumentieren ist sinnfrei. Artefakte sollen im Prozess auch einen erkennbaren Mehrwert für die späteren Prozessschritte bieten. Mockups sind z.B. sehr hilfreich, um auf ihrer Basis ein Datenmodell zu erzeugen. Und auf Basis des Datenmodells können dann wiederum Klassen modelliert werden usw. Durch den passenden Einsatz der Artefakte in den jeweiligen Prozessschritten füllt sich die Projektdokumentation automatisch mit spannenden Inhalten für die Prüfer:innen! :-D Anforderungen aufnehmen Ist-Analyse durchführen Bisherige Lösung untersuchen, Schwachstellen aufdecken. mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN, Screenshots/Fotos der bisherigen Lösung Anforderungen an neue Lösung strukturiert erfassen Interviews mit Stakeholdern führen Priorisierung der Anforderungen Ergebnis: z.B. User Stories, MoSCoW Anwendungsfälle modellieren Was wollen die Stakeholder mit der Anwendung fachlich machen/erreichen? Ergebnis: Use-Case-Diagramm Anforderungen strukturiert dokumentieren Ergebnis: Lastenheft Lösung entwerfen Neuen Ablauf bzw. neue Lösung skizzieren Was macht die (neue) Lösung besser? Welche Personen/Systeme sind wann/wie beteiligt? mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN Plattform bzw. Art der Anwendung festlegen: GUI, Web, App etc. Welche Anwendungsform löst das gestellte Problem am besten? Warum? Wie werden die Use-Cases umgesetzt? UI gestalten Daraus ergeben sich u.a. die benötigten Daten der Anwendung. Direkte Interaktion mit dem Kunden zur Abstimmung der Inhalte und Abläufe. Mögliche Ergebnisse: Mockups, Wireframes, Screendesigns, Workflows, Corporate Design, Aktivitätsdiagramm Datenmodell entwerfen Welche Entitätstypen mit welchen Attributen gibt es und wie hängen sie zusammen? Welche Anwendungsfälle benötigten welche Daten? Abstrakt und unabhängig von der konkreten späteren Speicherlösung modellieren. Ergebnis: Entity-Relationship-Modell Architektur der Anwendung modellieren Welche Architektur eignet sich am besten für die Umsetzung der Anforderungen? Beispiele: Domain Driven Design, MVC, Client/Server, Monolith, REST etc. Mögliche Ergebnisse: Komponentendiagramm, Klassendiagramm, Aktivitätsdiagramm, Sequenzdiagramm, Glossar Datenhaltung definieren Welche Daten müssen wie/wo gespeichert und übertragen werden? Beispiele: Datenbank, Dateien, Cloud, REST-API, JSON/XML etc. mögliche Ergebnisse: Nutzwertanalyse Programmiersprache und Frameworks auswählen Wenn eine Wahl möglich ist: Welche Sprachen/Frameworks eignen sich am besten für die Umsetzung? Warum? Hat die getroffene Wahl eine Auswirkung auf die Architektur? Muss sich die Anwendung dem Framework anpassen? Nach welchem Paradigma wird entwickelt? Wie wird getestet? mögliche Ergebnisse: Liste der eingesetzten Technologien, Nutzwertanalyse Geschäftslogik und Domäne grob planen Wie sollen die Anforderungen grob umgesetzt werden? Gibt es besonders "schwierige" Probleme? Welche Entitätstypen sind von zentraler Bedeutung? Wie hängen sie mit anderen zusammen? Gibt es einen Workflow durch das System? Wie werden die Daten ausgetauscht? Mögliche Ergebnisse: Aktivitätsdiagramm/EPK/BPMN, Sequenzdiagramm, Programmablaufplan, Struktogramm, Pseudocode, Klassendiagramm Build und Deployment modellieren Welche Komponente (UI, Logik, DB etc.) läuft wo? Wie/wo wird entwickelt? Welches Build-Tool soll eingesetzt werden? Wo läuft der Build? Welche Build-Schritte sind nötig? Welche Stages gibt es? Werden Container verwendet? Mögliche Ergebnisse: Deploymentdiagramm, Aktivitätsdiagramm, Sequenzdiagramm, Build-Pipeline, Dockerfile, Buildfile Qualitätssicherung planen Wie wird die Qualität bei der Softwareentwicklung sichergestellt? Welche Qualitätskriterien sind besonders wichtig? Wie wird die fachliche Qualität sichergestellt? Wer testet wann die Anwendung? Was kann automatisiert werden? Mögliche Ergebnisse: Testkonzept, Testplan, Branching-Strategie, Build-Pipeline, Schulungskonzept, zu erstellende Dokumentationen, statische Codeanalyse, Entwicklungsprozess (z.B. Pull Requests) Technische Lösung strukturiert dokumentieren Ergebnis: Pflichtenheft Lösung implementieren Vorgehen bei der Implementierung muss zum gewählten Prozess/Vorgehen passen Code First vs. Database First, TDD mögliche Ergebnisse: interessante Code-Beispiele: Frontend/Backend/SQL/HTML etc., Klassendiagramm, Sequenzdiagramm,...

Um alles rund um Verträge als Vorbereitung auf die AP1 geht es in der einhundertvierundachzigsten Episode des IT-Berufe-Podcasts. TL;DR Ich zeige dir anhand von IT-Beispielen, wie Verträge entstehen und welche Vertragsarten dir als IT-Azubi begegnen. Für die AP1, die 20 Prozent deiner Abschlussnote ausmacht, gehören dazu auch typische Vertragsinhalte sowie AGB und Service Level Agreements. Bei Softwareprojekten bestimmen Werkverträge und Dienstverträge, wofür du bezahlt wirst und welches Risiko du übernimmst. Außerdem erfährst du, welche Rolle Gewährleistung, gesetzliche Archivierungspflichten und Rechte an geschützten Werken spielen. Kapitelmarken [00:00:00] Vertragsthemen für die AP1 [00:03:22] Rechtlicher Hinweis und Umfang der Prüfungsvorbereitung [00:04:13] Wie Verträge entstehen [00:08:38] Vertragsformen und konkludentes Handeln [00:10:40] Vertragsarten im IT-Alltag [00:11:49] Kaufvertrag [00:12:42] Lizenzvertrag [00:15:07] Servicevertrag und Wartung [00:17:06] Mietvertrag [00:18:05] Eigentum und Besitz [00:19:49] Software mieten und steuerlich einordnen [00:20:53] Leasingvertrag [00:24:16] Zahlungen und Pflichten bei Kauf, Miete und Leasing [00:26:58] Werkvertrag für Softwareprojekte [00:28:47] Dienstvertrag und Vergütung nach Arbeitszeit [00:29:34] Vertragsarten bei klassischer und agiler Softwareentwicklung [00:33:42] Fernabsatzvertrag und Widerrufsrecht [00:37:54] Arbeitsvertrag [00:39:33] Typische Vertragsinhalte [00:41:13] Abnahme eines Werks [00:42:29] Vertragsstrafen und Haftung [00:43:21] Allgemeine Geschäftsbedingungen [00:46:36] Vorrang individueller Vereinbarungen [00:47:41] Salvatorische Klausel [00:49:55] Service Level Agreements [00:53:27] Unterschiedliche Service Levels und Preise [00:55:07] Gewährleistung und Garantie [00:56:38] Geschäftliche Unterlagen archivieren [00:58:01] Backup und revisionssicheres Archiv [00:59:51] Urheberrecht und Rechte an fremden Werken [01:03:19] Schutzfristen und gemeinfreie Werke [01:04:51] Creative Commons und Lizenzbedingungen [01:08:28] Bausteine der Creative-Commons-Lizenzen [01:11:16] Patente [01:13:19] Marken und ihr Schutz [01:17:01] Abschluss und Hinweise zur Ausbildungsbegleitung Inhalt Für die AP1 ist es sinnvoll, einige grundsätzliche Vertragsarten zu kennen und unterscheiden zu können. Sowohl auf Anbieter- als auch auf Nachfragerseite ist es wichtig zu verstehen, welche Art von Vertrag vorliegt, da daraus unterschiedliche Rechte und Pflichten entstehen können. Disclaimer: Das hier ist keine Rechtsberatung! :-) Vertrag Ein Vertrag ist die von zwei (oder mehr) Vertragsparteien erklärte Einigung über die Begründung eines Schuldverhältnisses (siehe § 311 BGB). Hierfür sind zwei übereinstimmende Willenserklärungen erforderlich. Beispiel: Angebot und Annahme, Bestellung und Lieferung. Verträge können schriftlich, mündlich oder durch "konkludentes Handeln" entstehen. Vertragsarten Kaufvertrag: Verkäufer:in verkauft etwas an Käufer:in. Beispiele in der IT: Hardware-/Softwarekauf Lizenzvertrag: Lizenzgeber:in räumt Lizenznehmer:in Rechte an einem geschützten Werk (z.B. Patent, Marke, Urheberrecht) ein. Beispiele in der IT: Lizenzierung von Software, Bildrechte einkaufen Servicevertrag: Regelt die Erbringung produktbezogener Leistungen zwischen Anbieter:in und Kund:in. Beispiele in der IT: Wartungsverträge für Software (z.B. für Patches und Updates) oder Hardware durch Dienstleister Mietvertrag: Vermieter:in überlässt Mieter:in eine bewegliche oder unbewegliche Sache zur zeitweisen Nutzung. Beispiele in der IT: Miete eines Autos für eine Dienstreise, Miete von Software Leasingvertrag: Leasinggeber:in (Vermieter:in) überlässt Leasingnehmer:in (Mieter:in) eine Sache zur Nutzung wie bei der Miete, aber mit Fokus auf eine langfristige Nutzung mit der Möglichkeit des Erwerbs am Ende der Vertragslaufzeit. Außerdem sind bestimmte Sachverhalte anders geregelt, z.B. die Inspektion beim geleasten Auto oder die Wahl des konkreten Modells und der Ausstattung durch den/die Leasingnehmer:in. Beispiele in der IT: Leasing teurer Hardware statt einmaligen Kaufs Werkvertrag: Unternehmer:in (Auftragnehmer:in) verpflichtet sich zur Herstellung eines bestimmten Werks für den/die Auftraggeber:in (Besteller:in). Hier muss das Endergebnis klar definiert sein ("Werk"). Beispiele in der IT: Programmierung einer kompletten Individualsoftware für eine Kundin Dienstvertrag: Schuldner:in verpflichtet sich zur Leistung eines Dienstes an den/die Gläubiger:in. Hierbei steht die Dienstleistung an sich im Vordergrund und nicht das Endergebnis. Beispiele in der IT: Programmierung für einen Kunden auf Basis von Tagessätzen Fernabsatzvertrag: Bei Verträgen, die über Fernkommunikationsmittel (Internet, Telefon usw.) geschlossen werden, haben Verbraucher:innen besondere Rechte, insb. ein Widerrufsrecht. Arbeitsvertrag: Definiert die Rechte und Pflichten von Arbeitgeber:in und Arbeitnehmer:in. Vertragsbestandteile z.B. Leistungsbeschreibung, Termine/Fristen, fällige Entgelte, Lasten- und Pflichtenheft (insb. bei Softwareerstellung), Konventionalstrafen, Haftung Allgemeine Geschäftsbedingungen (AGB) Mit AGBs regeln Unternehmen ihre grundsätzliche Vertragsgestaltung, also Inhalte, die für alle Verträge gelten. Beispielinhalte: Informationen zum Vertragsschluss (z.B. Telefon, E-Mail), Bestätigungen usw. Zahlungsbedingungen (z.B. Fristen, Zahlungsmöglichkeiten) Eigentumsvorbehalt Lieferungskonditionen und -möglichkeiten übliche Geschäftszeiten Gewährleistung/Garantie Haftung Service-Level-Agreement (SLA) Ein SLA legt fest, wie Auftraggeber:in und Dienstleister:in bei wiederkehrenden Dienstleistungen zusammenarbeiten und welche individuellen Verantwortlichkeiten sie tragen. Beispielinhalte: Leistungsbeschreibung: z.B. Hosting einer Website Verfügbarkeit des Services: z.B. Verfügbarkeit 99%, vereinbarte Wartungsfenster Erreichbarkeit des Dienstleisters: z.B. Geschäftszeiten, Reaktionszeit bei unterschiedlich schweren Problemen Preisgestaltung: z.B. Abrechnung pro Aufruf oder Kontingente Rechtsfolgen bei Nichteinhaltung: z.B. Vertragsstrafen Vertragslaufzeit: z.B. monatlich, jährlich Sonstiges Gewährleistung vs. Garantie: Gewährleistungsrechte bestehen aufgrund gesetzlicher Vorschriften gegenüber dem/der Verkäufer:in. Eine Garantie ist eine freiwillige Leistung eines/einer Hersteller:in und richtet sich nach dessen/deren Bedingungen. Archivierung: Jede:r Gewerbetreibende ist verpflichtet, geschäftliche Unterlagen (also auch Verträge) über einen bestimmten Zeitraum aufzubewahren. Die übliche Aufbewahrungsfrist beträgt 10 Jahre. Urheberrecht: Verleiht dem/der Inhaber:in das exklusive Nutzungsrecht am Werk, auch 70 Jahre über den Tod hinaus (Schutz geistigen Eigentums). Gilt automatisch für Bilder, Videos, Musik, Texte usw. mit einer gewissen Schöpfungshöhe. Das Urheberrecht ist nicht vertraglich abtretbar, aber Lizenzen können erteilt werden. Creative Commons: Gemeinnützige Organisation, die verschiedene Standard-Lizenzverträge veröffentlicht hat, mit denen Autor:innen der Öffentlichkeit auf einfache Weise Nutzungsrechte an ihren Werken einräumen können. Achtung: Lizenzen geben einzuhaltende Pflichten vor, z.B. die Namensnennung. Patent: Hoheitlich erteiltes gewerbliches Schutzrecht für eine (technisch geprägte) Erfindung. Dies verhindert eine schnelle Nachahmung durch Konkurrenten und motiviert die Forschung und Entwicklung neuer Erfindungen. Marke: Rechtlich geschütztes Zeichen, das dazu dient, Waren, Produkte oder Dienstleistungen eines Unternehmens von der Konkurrenz zu unterscheiden. Literaturempfehlungen * Und dazu passend das Arbeitsbuch: * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Vertrag - Wikipedia Beispiel für AGBs: AGB von Mindfactory Abgemahnter Schlangenkuchen und Bilderrechte – Rechtsbelehrung Folge 1 (Jura-Podcast) Zusammenfassung Verträge als Thema für die AP1 Ich bereite dich mit Beispielen aus dem IT-Alltag auf die Vertragsthemen der AP1 vor. Sie macht 20 Prozent deiner Abschlussnote aus. Die rechtlichen Begriffe sind vereinfacht beschrieben und dienen dazu, für die Prüfung zu lernen. Für rechtliche oder steuerliche Fragen brauchst du fachlichen Rat von einem/einer Rechtsanwält:in beziehungsweise Steuerberater:in. Wie ein Vertrag entsteht Ein Vertrag entsteht, wenn sich mindestens zwei Vertragsparteien durch übereinstimmende Willenserklärungen einigen. Dadurch begründen sie ein Schuldverhältnis, bei dem beispielsweise eine Partei eine Leistung erbringt und die andere dafür bezahlt. Beim Kauf eines PCs können Angebot und Annahme diese Willenserklärungen sein: Ein:e Verkäufer:in bietet dir den Rechner für 1.000 Euro an, und du akzeptierst den Preis. Bei einer Onlinebestellung kann die anschließende Lieferung die Annahme darstellen. Du kannst einen Vertrag schriftlich oder mündlich schließen. Durch konkludentes Handeln zeigst du dein Einverständnis mit deinem Verhalten, etwa wenn du beim Bäcker ein Brötchen entgegennimmst und bezahlst. Für bestimmte Verträge gelten besondere Formvorgaben. Welche Form jeweils erforderlich ist, musst du beim konkreten Vertrag prüfen. Vertragsarten im IT-Alltag Kaufvertrag Ein:e Verkäufer:in verkauft einem/einer Käufer:in eine Sache zum vereinbarten Preis. In der IT betrifft das beispielsweise Rechner oder Software. Beim Kauf fällt der vereinbarte Kaufpreis an; die gekaufte Sache geht in dein Eigentum über. Lizenzvertrag Ein:e Lizenzgeber:in räumt einem/einer Lizenznehmer:in Rechte an einem geschützten Werk ein. Der Vertrag legt fest, was du mit dem Werk machen darfst und wie lange die Rechte gelten. Bei einem Foto kann beispielsweise geregelt sein, ob du es bearbeiten oder auf deiner Website veröffentlichen darfst. Für Software kommen auch zeitlich begrenzte Lizenzen vor, die du nach Ablauf verlängern musst. Ebenso begegnen dir Lizenzverträge bei Stockfotos sowie bei Rechten an Patenten und Marken. Servicevertrag ...

Um Softwarequalität nach ISO 9126 geht es in der einhundertdreiundachzigsten Episode des IT-Berufe-Podcasts. TL;DR Softwarequalität bedeutet, dass Software die Anforderungen erfüllt, die an sie gestellt werden. Ich gehe mit dir die sechs Qualitätsmerkmale der ISO 9126 und ihre Unterpunkte durch, die du als IT-Azubi in der Anwendungsentwicklung für die Praxis und die AP2 kennen solltest. Dazu gehören konkrete Maßnahmen wie Code Reviews und automatisierte Tests, mit denen du die Qualität während der Entwicklung und im späteren Betrieb sicherst. Die ISO 9126 wurde durch die ISO 25010 abgelöst, wobei viele ihrer Begriffe übernommen wurden. Kapitelmarken [00:00:00] Softwarequalität in Praxis und Prüfung [00:03:34] Qualität als Übereinstimmung mit Anforderungen [00:05:00] Stakeholder:innen und Anforderungen priorisieren [00:06:37] Funktionale und nicht-funktionale Anforderungen [00:08:50] Maßnahmen zur Qualitätssicherung [00:10:22] Code Reviews und Tests [00:12:56] Entwicklungsprozess und Dokumentation [00:14:30] Statische Codeanalyse, Pair Programming und Bug-Tracker [00:16:02] Automatisierte Qualitätssicherung mit CI/CD [00:17:16] ISO 9126 und ihre Nachfolgerin ISO 25010 [00:19:25] Die sechs Qualitätsmerkmale der ISO 9126 [00:20:47] Funktionalität und ihre Unterpunkte [00:25:26] Benutzbarkeit und verständliche Oberflächen [00:30:35] Änderbarkeit und langfristig wartbarer Code [00:32:01] Analysierbarkeit und Modifizierbarkeit [00:34:20] Testbarkeit durch Dependency Injection [00:36:12] Stabilität und Regressionstests [00:38:15] Effizienz: Ressourcenverbrauch und Laufzeit [00:42:03] Wo sich das Optimieren lohnt [00:43:46] Übertragbarkeit auf andere Umgebungen [00:47:43] Koexistenz und konfigurierbare Netzwerkports [00:49:27] Zuverlässigkeit: Fehlertoleranz und Reife [00:52:22] Wiederherstellbarkeit nach Fehlern [00:54:37] Schwerpunkte für die Anwendungsentwicklung [00:56:14] Ausblick auf ISO 25010 [00:56:39] Shownotes und Newsletter Inhalt Definition von Qualität Qualität ist der Grad der Übereinstimmung mit den Anforderungen. Da verschiedene Stakeholder unterschiedliche Anforderungen an unser Projekt haben, ist die Qualität recht subjektiv. Alle Stakeholder zu 100% zufrieden zu stellen, wird in einem echten Projekt wohl nicht möglich sein. Maßnahmen zur Qualitätssicherung Die Softwarequalität kann mit verschiedenen konkreten Maßnahmen während der Entwicklung sichergestellt werden. Diese nicht vollständige Liste enthält einige Maßnahmen, die Prüflinge auch in ihrem eigenen Abschlussprojekt anwenden können. Audits Code Reviews Testmethoden Entwicklungsprozess Dokumentation Statische Codeanalyse Pair Programming Bugtracking Continuous Integration/Delivery/Deployment Softwarequalität nach ISO 9126 Funktionalität Angemessenheit Interoperabilität Ordnungsmäßigkeit Richtigkeit Sicherheit Änderbarkeit Analysierbarkeit Modifizierbarkeit Testbarkeit Stabilität Übertragbarkeit Anpassbarkeit Austauschbarkeit Installierbarkeit Koexistenz Effizienz Verbrauchsverhalten Zeitverhalten Zuverlässigkeit Fehlertoleranz Reife Wiederherstellbarkeit Benutzbarkeit Attraktivität Bedienbarkeit Erlernbarkeit Verständlichkeit Literaturempfehlungen Hier gibt es diese Podcast-Episode noch einmal als Video bei YouTube: Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Video zur Podcast-Episode bei YouTube ISO/IEC 9126 in der Wikipedia Zusammenfassung Anforderungen erfüllen Wenn ich die Qualität meiner Software bewerte, prüfe ich, wie gut sie die Anforderungen erfüllt. Diese stammen von verschiedenen Stakeholder:innen, also Personen, die ein berechtigtes Interesse am Projekt haben. Weil jede Person eigene Anforderungen mitbringt, hängt das Urteil über die Qualität von ihrer Perspektive ab. Bei einem Passagierflugzeug braucht ein:e Pilot:in beispielsweise verständliche Instrumente im Cockpit. Für eine:n Passagier:in spielt die Beinfreiheit eine Rolle. Anforderungen können miteinander konkurrieren, weshalb du ihre Priorität festlegen und festhalten solltest, von wem sie stammen. Eine User-Story hält diesen Zusammenhang fest: "Als Rolle möchte ich Funktionalität, damit …". Die Rolle zeigt, wer die Anforderung stellt; die Begründung beschreibt ihren Zweck. Funktionale und nicht-funktionale Anforderungen Funktionale Anforderungen beschreiben, welche fachlichen Aufgaben die Software erfüllen soll. Eine Rechnungswesen-Software muss beispielsweise Buchungssätze verarbeiten und eine Bilanz erstellen können. Nicht-funktionale Anforderungen betreffen Eigenschaften wie die Geschwindigkeit oder die Frage, wie gut sich der Code später ändern lässt. Für einen Buchungssatz lässt sich etwa festlegen, wie lange die Software dafür brauchen darf. Die ISO-Normen und deine Prüfung Die ISO 9126 beschreibt international standardisierte Kriterien für Softwarequalität. Sie wurde durch die ISO 25010 abgelöst, die viele Begriffe übernimmt und weitere Kriterien enthält. Hier behandle ich die ISO 9126 mit den deutschen Begriffen. Auch die englischen Bezeichnungen gehören zum IT-Alltag, insbesondere beim Lesen von Fachliteratur. Für die AP2 als Fachinformatiker:in Anwendungsentwicklung solltest du alle sechs Hauptmerkmale aufzählen und erklären können. Zu jedem Hauptmerkmal solltest du außerdem ein bis zwei Unterpunkte kennen. Konkrete Beispiele helfen dir, im Fachgespräch zu beschreiben, was du in deinem Abschlussprojekt umgesetzt hast. Die sechs Qualitätsmerkmale der ISO 9126 Funktionalität Bei meiner Rechnungswesen-Software prüfe ich unter diesem Merkmal, ob sie die vorgesehenen Geschäftsprozesse fachlich erfüllt. Dazu gehören fünf Unterpunkte: Angemessenheit: Die Software bildet die Aufgabe mit einem passenden Aufwand ab. Wie viele Schritte zum Buchen erforderlich sind, sollte zur Aufgabe passen. Interoperabilität: Über Schnittstellen arbeitet die Software mit anderen Anwendungen zusammen. Beispielsweise müssen Buchhaltungsdaten an die Software einer Steuerberater:in übermittelt werden können. Ordnungsmäßigkeit: Die Software hält geltende Vorgaben ein, etwa die Grundsätze der ordnungsgemäßen Buchführung oder einschlägige Standards. Richtigkeit: Fachliche Ergebnisse müssen korrekt sein. Bei der Rechnung 5 + 3 muss das Ergebnis 8 herauskommen, was sich mit einem Unit-Test prüfen lässt. Sicherheit: Die Software schützt Daten und setzt erforderliche Berechtigungen um. Wenn eine Überweisung ab einer bestimmten Summe genehmigt werden muss, braucht sie dafür ein Rollen- und Berechtigungskonzept mit entsprechender Authentifizierung. Benutzbarkeit Wer mit deiner Software arbeitet, soll die vorgesehenen Aufgaben gut erledigen können. Die ISO 9126 unterscheidet dabei vier Unterpunkte: Attraktivität: Eine ansprechend gestaltete Oberfläche trägt dazu bei, dass Anwender:innen mit der Software arbeiten möchten. Bedienbarkeit: Die Software berücksichtigt Barrierefreiheit und die Erfahrung der jeweiligen Anwender:in. Für Einsteiger:innen kann ein Assistent hilfreich sein, während sich Hilfen nach dem Einstieg ausblenden lassen sollten. Erlernbarkeit: Dokumentation und eingeblendete Hilfen unterstützen neue Anwender:innen dabei, sich einzuarbeiten. Verständlichkeit: Begriffe und Abläufe müssen nachvollziehbar sein. Ein ausgeschriebenes "Umsatzsteuer" erleichtert das Verständnis eines Formularfelds, dessen Beschriftung sonst nur "UST" lautet. Abkürzungen können außerdem mehrdeutig sein, wie DSL für "Digital Subscriber Line" und "Domain-Specific Language". Änderbarkeit Wenn ich nach einem halben Jahr wieder an meinem Code arbeite, muss ich mich erneut darin zurechtfinden. Dieses Merkmal betrifft die Entwickler:innen, die die Software langfristig pflegen und erweitern. Analysierbarkeit: Fehler und ihre Ursachen lassen sich nachvollziehen. Logdateien können dafür den Zeitpunkt eines Fehlers sowie eine Exception mit Stacktrace festhalten. Modifizierbarkeit: Der Code lässt sich mit überschaubarem Aufwand anpassen. Design Patterns und die SOLID-Prinzipien unterstützen das. Beim Open-Closed-Prinzip erfolgt eine Erweiterung beispielsweise über eine zusätzliche Klasse, während bestehende Klassen unverändert bleiben. Testbarkeit: Wie du den Code gestaltest, beeinflusst, wie gut sich einzelne Komponenten testen lassen. Durch Dependency Injection erhält eine Klasse ihre Abhängigkeiten von außen. Im Test kann dann eine Fake-Datenbank über ein Interface übergeben werden, sodass die Komponente isoliert geprüft werden kann. Stabilität: Nach einer Änderung sollen die bereits vorhandenen Funktionen weiterhin arbeiten. Regressionstests prüfen das und können bei jedem Build in einer CI/CD-Pipeline laufen. Auch indirekte Abhängigkeiten zwischen Komponenten müssen dabei berücksichtigt werden. Effizienz Für meine Anwendung muss ich abwägen, welche Anforderungen an Laufzeit und Ressourcenverbrauch bestehen. Dabei können Zielkonflikte entstehen, etwa wenn ein Algorithmus durch zusätzlichen Speicher schneller arbeitet. Verbrauchsverhalten: Hier geht es um begrenzte Ressourcen wie Arbeitsspeicher oder Netzwerkbandbreite. Auch der Platz auf der Festplatte zählt dazu. Zeitverhalten: Dazu gehören die Laufzeit und die Komplexität von Algorithmen, die sich mit der Big-O-Notation beschreiben lässt. Ein In-place-Sortieralgorithmus arbeitet auf dem vorhandenen Array. Andere Verfahren benötigen zusätzlichen Speicher. Welche Lösung passt, hängt unter anderem von der Datenmenge und davon ab, wie häufig die Aufgabe ausgeführt wird. Beim Optimieren solltest du Zeit dort investieren, wo sie sich auf die Anwendung auswirkt. Bei einer Web-Anwendung können Netzwerkwege oder das Rendern im Browser die Antwortzeit bestimmen. Für eine Echtzeitanwendung, beispielsweise den Notaus einer Maschine, müssen die vorgegebenen Reaktionszeiten zuverlässig eingehalten werden. Hoher Ressourcenverbrauch wirkt sich außerdem auf den Stromverbrauch und auf andere Anwendungen aus. Übertragbarkeit Wenn meine Software in einer anderen Umgebung laufen oder später abgelöst werden s

Um Eigenschaften und Unterscheidungsmerkmale von Programmiersprachen geht es in der einhundertzweiundachzigsten Episode des IT-Berufe-Podcasts. TL;DR Ich gebe dir Kriterien an die Hand, mit denen du die Programmiersprachen deines Abschlussprojekts im Fachgespräch beschreiben und für eine Aufgabe auswählen kannst. Dazu gehören das Programmierparadigma, die Art, wie Code ausgeführt wird, und weitere Merkmale wie Syntax oder Speicherverwaltung. Bei der Typisierung unterscheidest du zwei unabhängige Dimensionen: statisch oder dynamisch sowie stark oder schwach. Auch die Plattform und das Ökosystem gehören zum Wissen, das du beim Entwickeln brauchst. Kapitelmarken [00:00:00] Einstieg und Bedeutung für das Fachgespräch [00:02:56] Was ist eine Programmiersprache? [00:04:38] Grundbausteine von Algorithmen [00:06:37] Turing-Vollständigkeit und andere Spracharten [00:09:38] Sprache, Plattform und Ökosystem [00:12:44] Klassenbibliotheken und Laufzeitplattformen [00:15:12] Buildtools, Abhängigkeiten und Frameworks [00:17:47] Einsatzzweck von Programmiersprachen [00:19:24] Frontend und Backend [00:20:06] Skriptsprachen und Websprachen [00:23:29] Programmierparadigmen und First Class Citizens [00:25:15] Idiomatischer Code und Multiparadigmen-Sprachen [00:28:29] Imperative und deklarative Programmierweise [00:34:52] Unstrukturierte Programmierung mit goto [00:37:11] Strukturierte Programmierung [00:37:44] Prozeduren und Funktionen [00:39:00] Objektorientierung und Kapselung [00:41:20] Funktionale Programmierung [00:43:47] Logische Programmierung mit Prolog [00:47:00] Compiler und Interpreter [00:48:50] Bytecode und Just-in-Time-Compiler [00:50:35] Typisierung als Prüfungsthema [00:51:46] Die unabhängigen Dimensionen der Typisierung [00:52:58] Statische und dynamische Typisierung [00:55:03] Typinferenz [00:57:47] Starke und schwache Typisierung [01:00:00] Implizite Typumwandlungen und Fehlerquellen [01:05:07] Beispiele für die vier Typisierungskombinationen [01:06:49] Typfehler und Tests [01:08:09] C-ähnliche Syntax und andere Schreibweisen [01:09:41] Grafische Programmiersprachen [01:10:30] Sprachhöhe und Generationen von Programmiersprachen [01:13:29] 4GL-Sprachen mit SQL, Natural und ABAP [01:16:51] General Purpose und Domain-Specific Languages [01:18:49] Interne und externe DSLs [01:19:46] Portabilität und virtuelle Maschinen [01:21:07] Managed und unmanaged Speicher [01:22:24] Garbage Collection und Echtzeitsysteme [01:25:52] Performance und Speicherverbrauch [01:28:15] Beispiele für Websprachen und TypeScript [01:30:15] Sprachen für Anwendungen in Unternehmen [01:32:19] Appentwicklung und Hardware-nahe Sprachen [01:33:30] Funktionale Sprachen und Elixir [01:35:02] Prolog und andere Denkweisen beim Programmieren [01:35:59] Buchempfehlung Seven Languages in Seven Weeks [01:37:06] Kriterien für eine Antwort im Fachgespräch [01:39:20] Java anhand der Kriterien beschreiben [01:40:47] Fragen, Shownotes und Newsletter Inhalt Was ist eine Programmiersprache? Programmiersprache: "Eine Programmiersprache ist eine formale Sprache zur Formulierung von Datenstrukturen und Algorithmen, d.h. von Rechenvorschriften, die von einem Computer ausgeführt werden können." [Herv. d. Verf.] Bausteine von Algorithmen: Sequenz, Verzweigung (z.B. if, switch, aber auch Pattern Matching), Wiederholung (GOTO, Schleifen, Rekursion) Turing-complete: "[...] die Eigenschaft einer Programmiersprache oder eines anderen logischen Systems, sämtliche Funktionen berechnen zu können, die eine universelle Turingmaschine berechnen kann." Demnach sind keine Programmiersprachen: HTML/XML (Auszeichnungssprache), CSS (Stylesheet-Sprache), SQL (Datenbankabfragesprache). Sprache vs. Plattform vs. Ökosystem Programmiersprachen bringen meistens "eingebaute" ("native") Funktionen mit, die direkt in der Syntax der Sprache formuliert werden können: Ein-/Ausgabe-Befehle, um Daten verarbeiten zu können Deklaration von Variablen zum Speichern von Informationen mathematische Funktionen wie Addition, Multiplikation usw. Steueranweisungen für Verzweigung und Wiederholung Möglichkeiten zur Programmunterteilung (z.B. Funktionen, Subprogramme) Einbinden von (externen) Bibliotheken zur Wiederverwendung Viele Programmiersprachen bringen außerdem noch eine umfangreiche Bibliothek an vorgefertigten Implementierungen (z.B. in Form von Klassen in objektorientierten Sprachen) mit. Diese Bibliothek ist bei der Einarbeitung in eine neue Sprache meist schwieriger/langwieriger zu lernen als die Syntax. Oftmals teilen sich mehrere Programmiersprachen die Bibliotheken einer gemeinsamen Plattform, z.B. der JVM bei Java und Kotlin bzw. .NET bei C# und Visual Basic. Darüber hinaus existiert meist auch noch ein ganzes Ökosystem rund um die Sprache/Plattform: Build-Tools, z.B. Maven, Gradle Dependency-Management, z.B. NPM, RubyGems Test-Frameworks, z.B. JUnit weitere Frameworks und Libraries, z.B. Spring, Jakarta EE, Rails, Blazor Klassifizierung/Einsatzzweck(e) Im Alltag sind die Identifikation und Auswahl einer für das jeweilige "Realweltproblem" passenden Sprache wichtig. Viele Programmiersprachen haben Schwerpunkte bei ihrem Einsatz, weil sie für bestimmte Einsatzzwecke optimiert wurden oder dafür viele vorgefertigte Lösungen mitbringen. Einsatzzweck: Webanwendung (z.B. PHP), App (z.B. Swift), Desktop-Anwendung (z.B. C#), Server-Anwendung (z.B. Java) Frontend (browserseitig) vs. Backend Scriptsprachen: geringer Programmieraufwand für schnell sichtbare Ergebnisse, oft Interpretersprachen mit dynamischer Typisierung und laxer Syntaxprüfung (z.B. Semikolons optional), Beispiele: PowerShell, PHP Web-Programmiersprachen: bringen meist umfangreiche Bibliotheken und Frameworks für Webanwendungen mit, oftmals auch Scriptsprachen, Beispiele: PHP, Ruby, Python Programmierparadigma Ein Programmierparadigma gibt die grundsätzliche Art und Weise vor, wie mit einer Programmiersprache entwickelt wird. Es definiert grundlegende Herangehensweisen und Prinzipien bei der Softwareentwicklung, aber auch ganz konkrete syntaktische Vorgaben. So legt es z.B. fest, mit welchen Konstrukten das Programm hauptsächlich arbeitet (z.B. Objekte in der Objektorientierung bzw. Funktionen in der funktionalen Programmierung als sogenannte "First Class Citizens"), wie Programme modularisiert werden sollten und auf welche Art und Weise Algorithmen vorzugsweise formuliert werden sollten ("idiomatische Programmierung"). Viele Programmiersprachen sind heutzutage sogenannte Multiparadigmensprachen, bieten also Konzepte aus mehreren Paradigmen an, z.B. Objektorientierung und funktionale Programmierung. Meist haben sie aber ein definierendes Paradigma, z.B. Objektorientierung bei Java. Imperativ vs. Deklarativ Grundsätzlich kann man die imperative und deklarative Programmierung unterscheiden. Während bei der imperativen Programmierung (von lat. "imperare" - befehlen) exakt vorgegeben wird, in welcher Reihenfolge der Computer welche Befehle wie ausführen muss, gibt man bei der deklarativen Programmierung (von lat. "declarare" - erklären) lediglich vor, welches Ergebnis am Ende erreicht sein soll, und lässt den Computer den Weg dorthin selbst finden. Beispiel: // imperativ for (int i = 0; i < list.getSize(); i++) { System.out.println(list.get(i)); } // deklarativ list.forEach(System.out::println); Konkrete Programmierparadigmen unstrukturiert: Einsatz von GOTO führte dazu, dass konkrete Programmabläufe nicht mehr nachvollzogen werden konnten strukturiert: Verzicht auf GOTO und Einsatz von Kontrollstrukturen wie if und while prozedural: Programme werden in kleine, wiederverwendbare Einheiten ("Prozeduren") aufgespalten funktional: (mathematische) Funktionen bilden den Kern dieser Vorgehensweise, Higher Order Functions, Immutability und Rekursion als wichtige Merkmale objektorientiert: Objekte kapseln Eigenschaften und Funktionen zu einer Einheit, Vererbung und Polymorphie als wichtige Merkmale logisch: Programmierung auf Basis der mathematischen Aussagenlogik Compiler vs. Interpreter Compiler: Übersetzt Quellcode in Maschinen- oder Bytecode, bevor das Programm ausgeführt wird. JIT-Compiler: Just-In-Time-Compiler übersetzen z.B. Teile des Bytecodes zur Laufzeit in Maschinencode, um die Performance zu erhöhen. Interpreter: Interpretiert den Quellcode Zeile für Zeile und übersetzt ihn während der Ausführung in Maschinencode. Typisierung statisch vs. dynamisch statisch: Datentypen stehen schon zur Compile-Zeit fest. dynamisch: Datentypen werden erst zur Laufzeit geprüft. stark vs. schwach: eher ein Spektrum ("stärker/schwächer typisiert") als eine harte Einteilung stark: keine Typumwandlung möglich oder nur explizit ("Cast", (int)3.5) schwach: implizite Typumwandlungen durch die Sprache, z.B. if (1) { ... } Beispiele für alle Kombinationen statisch/stark: Java > cat .\Main.java class Main { public static void main(String[] args) { double d = 1.5; int i = d; } } > javac .\Main.java .\Main.java:6: error: incompatible types: possible lossy conversion from double to int int i = d; ^ 1 error statisch/schwach: C > cat test.c #include int main() { int i = 1; if (i) { printf("Hallo\n"); } return 0; } > gcc test.c -o test > ./test Hallo dynamisch/stark: Ruby > cat .\test.rb i = 1 s = "a" puts i + s > ruby .\test.rb ./test.rb:3:in `+': String can't be coerced into Integer (TypeError) from ./test.rb:3:in `' dynamisch/schwach: PHP > cat test.php $i = "asdf"; if ($i) { echo "Hallo\n"; } > php test.php Hallo Syntax Syntaktisch gibt es eigentlich nur die Unterscheidung zwischen Sprachen, die ähnlich zu C sind (insb. Klammern, Schlüsselwörter, Datentypen) oder eben nicht. Beispiel Java (C-ähnlich): void pruefePerson(int alter) { if (alter >= 18) { System.out.println("volljährig"); } } Beispiel Ruby: def pruefePerson(alter) puts "volljährig" if alter >= 18 end ...

In dieser Sonder-Episode des IT-Berufe-Podcasts geht es um eine Stellenausschreibung als Softwareentwickler:in (m/w/d) bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG in Vechta. Inhalt Bei meinem Arbeitgeber, der ALTE OLDENBURGER Krankenversicherung AG aus Vechta, suchen wir zum nächstmöglichen Zeitpunkt Unterstützung im IT-Bereich. Wir schreiben aktuell eine Stelle als Softwareentwickler:in aus. Selbstverständlich sind Bewerbungen von Personen aller Geschlechter erwünscht. Kurzübersicht der Stelle Bezeichnung: Softwareentwickler (m/w/d) Art der Anstellung: unbefristete Festanstellung Arbeitsort: ALTE OLDENBURGER Krankenversicherung AG, Alte-Oldenburger-Platz 1, 49377 Vechta Homeoffice: bis zu 60% der wöchentlichen Arbeitszeit können im Homeoffice erbracht werden Beginn: schnellstmöglich Sonderleistungen: Urlaubs- und Weihnachtsgeld (14 Gehälter), Fahrtkostenzuschuss zur Arbeitsstelle, 40 EUR vermögenswirksame Leistungen pro Monat, Firmenfitness, Mitarbeiterrabatte für Versicherungen, betriebliche Altersvorsorge, Kinderbetreuungszuschuss Wöchentliche Arbeitszeit: 38 Stunden im Gleitzeitmodell ohne Kernarbeitszeit (bei einer Vollzeitbeschäftigung) Jährlicher Urlaubsanspruch: 30 Tage zusätzlicher Urlaub: Möglichkeit zur Umwandlung eines Teils des Urlaubsgelds in 5 Tage zusätzlichen Urlaub Weiterbildungsmöglichkeiten: (Duales) Studium (z.B. Wirtschaftsinformatik, technische Informatik), IHK-Weiterbildungen, externe Technologieschulungen, Konferenzbesuche Sonstiges: frisches Obst, kostenlose Kaffeespezialitäten, modern und ergonomisch ausgestattete Arbeitsplätze (überall höhenverstellbare Tische), betriebliche Gesundheitsförderung, eine kostenfreie Rückenmassage pro Monat (außerhalb der Arbeitszeit), ein hervorragendes Betriebsrestaurant mit bezuschussten Speisen, ein Employee-Assistance-Program, viele gemeinsame Aktivitäten wie z.B. Weihnachtsfeier, Betriebsausflug oder Spargelessen Technische Highlights der Arbeit bei der AO Moderne IT-Infrastruktur Windows 10 und SUSE Linux Virtualisierung mit Citrix und VMware Moderne Softwareentwicklung Continuous Integration und Deployment Test Driven Development, Unit-Tests, Codeanalyse Java, Jakarta EE, JBoss/Wildfly, Quarkus Fokus auf optimale Kollaboration Code Reviews, Pair Programming, Pull Requests Fokus auf DevOps Gute Zusammenarbeit zwischen Administration und Entwicklung Auf- und Ausbau der Container-Infrastruktur mit Docker und Kubernetes Tools: Gitea, Jenkins, Gradle, Artifactory, SonarQube Detailinformationen zur Stelle Unter dem folgenden Link kannst du dir alle Details zu der ausgeschriebenen Stelle anschauen und findest auch die notwendigen Daten für deine Bewerbung bei uns. Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen Wir suchen zum nächstmöglichen Zeitpunkt einen Softwareentwickler (m/w/d) in Festanstellung, der uns bei der Umsetzung von Fachbereichsanforderungen unterstützt und Systeme weiterentwickelt und optimiert. Deine Schwerpunkte liegen auf der Java-Plattform, sowie der Entwicklung in der Programmiersprache Natural der Software AG. Deine Aufgaben Weiterentwicklung/Betreuung des Outputmanagementsystems Schnittstellen-Entwicklung zur Anbindung diverser Anwendungen an das Bestandsführungssystem Sicherstellung von Performance, Wartbarkeit und Skalierbarkeit der betreuten Anwendungen Selbstständige Mitarbeit in Projekten Zusammenarbeit mit den angrenzenden IT-Abteilungen und Fachbereichen Deine neue Abteilung Die Abteilung IT-Anwendungsintegration freut sich auf dich! Neben den genannten Tätigkeiten ist die Abteilung auch für den Betrieb und die Weiterentwicklung weiterer Drittanbietersoftwareprodukte verantwortlich (bspw. das Enterprise-Content-Management-System, das Inputmanagemensystem, diverse Spezialanwendungen für die Arbeit in den Fachabteilungen). Teile der Entwicklung des Bestandsführungsssystems werden auch in unserer Abteilung durchgeführt. Zu Beginn deine Tätigkeit bei der AO bekommst du einen erfahrenen Mentor an die Seite gestellt, der dir alle Fragen beantworten kann und dich in die ersten Aufgaben und Projekte einführt. Sowohl die technischen Systeme, als auch das Unternehmen selbst und unsere Produkte werden dir in kurzen Schulungen nähergebracht. Fachlich wirst du von den jeweiligen Teammitgliedern betreut und in die Infrastruktur eingeführt. Die ALTE OLDENBURGER gehört übrigens zu den Siegern der Arbeitgeber-Wettbewerbe des internationalen Forschungs- und Beratungsinstituts Great Place to Work. Die ALTE OLDENBURGER zählt zu den zehn "Besten Arbeitgebern Niedersachsen/Bremen 2023" und wurde darüber hinaus sogar auch als einer von 100 "Deutschlands besten Arbeitgebern 2023" ausgezeichnet. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Softwareentwickler (m/w/d) für das Outputmanagementsystem und Drittanbieterschnittstellen bei der ALTE OLDENBURGER Krankenversicherung AG in Vechta

Um Zahlensysteme, Zweierpotenzen und vor allem Binärzahlen geht es in der einhunderteinundachzigsten Episode des IT-Berufe-Podcasts. Der Inhalt ist auch als Video bei YouTube verfügbar. TL;DR Ich zeige dir, wie du mit Zweierpotenzen zwischen Binärzahlen und Dezimalzahlen rechnest und die möglichen Werte einer Bitfolge bestimmst. Mit n Bit lassen sich 2^n Kombinationen darstellen, wodurch du etwa die Zahl der Adressen in einem Subnetz oder die Farben eines Bildes berechnen kannst. Beispiele aus Zeichencodes und Netzwerkadressen machen deutlich, wo dir dieses Wissen als IT-Azubi begegnet. Fürs Kopfrechnen lasse ich meine IT-Azubis häufige Zweierpotenzen lernen; bei größeren Werten reicht für viele Aufgaben die ungefähre Größenordnung. Kapitelmarken [00:00:00] Einführung: Zweierpotenzen in der IT-Ausbildung [00:01:46] Anwendungsfälle und Ablauf [00:02:56] Zahlen, Ziffern und Zahlensysteme [00:04:42] Römische Zahlen und ihre Rechenregeln [00:09:21] Dezimalsystem: Stellenwerte und die Null [00:13:19] Binärsystem: Basis 2 und der Begriff Bit [00:16:45] Hexadezimalzahlen in Dezimalzahlen umrechnen [00:19:24] Das Oktalsystem [00:20:22] Zweierpotenzen und binäre Stellenwerte [00:22:35] Dezimalzahlen als Binärzahlen schreiben [00:24:59] Zweierpotenzen fürs Kopfrechnen lernen [00:27:47] Anzahl möglicher Werte mit n Bit [00:32:15] Hostadressen beim Subnetting berechnen [00:33:51] ASCII und ISO-8859-1 [00:36:09] TCP-Ports und 16 Bit [00:39:22] RGB-Farbtiefe mit 24 Bit [00:41:36] IPv4-Adressen mit 32 Bit [00:43:04] MAC-Adressen und hexadezimale Schreibweise [00:47:10] 64-Bit-CPUs und IPv6 mit 128 Bit [00:50:15] Zweierpotenzen im Überblick und Base64 [00:52:36] Weitere Beispiele: Bildformate, Audio und Datentypen [00:53:30] Große Zweierpotenzen überschlagen [00:54:46] Größenvergleiche mit großen Zahlen [00:57:22] IPv6, MD5 und UUIDs mit 128 Bit [00:57:50] Wie viele Bit für alle Atome im Universum? [00:59:32] Video und Newsletter zur IT-Ausbildung Zahlensysteme, Zweierpotenzen und Binärzahlen Zweierpotenzen und Binärzahlen begegnen uns in der IT-Ausbildung an vielen Stellen. In dieser Episode erkläre ich die Funktionsweise von Zahlensystemen (Binär, Oktal, Dezimal, Hexadezimal) und gebe Beispiele für den Praxiseinsatz. Das Video zu dieser Episode findest du bei YouTube hier: Zahlensysteme, Zweierpotenzen und Binärzahlen. Zahlen vs. Ziffern Zahlen werden aus einzelnen Ziffern zusammengesetzt. Die Dezimalzahl 123 besteht z.B. aus den Ziffern 1, 2 und 3. Die bekannten Zahlensysteme haben unterschiedlich viele Ziffern: Dualsystem: 0 und 1 Oktalsystem: 0 bis 7 Dezimalsystem: 0 bis 9 (unsere bekannten arabischen Ziffern) Hexadezimalsystme: 0 bis 9 und A bis F Römische Zahlen Das römische Zahlsystem hat auch mehrere Ziffern: I = 1 V = 5 X = 10 L = 50 C = 100 D = 500 M = 1.000 Anders als in den anderen Zahlensystemen werden die einzelnen Ziffern hier einfach aufaddiert. So entspricht die Zahl III der Dezimalzahl 3, da I + I + I = 3. Außerdem können Ziffern abhängig von ihrer Platzierung in der Zahl eine unterschiedliche Bedeutung haben. MCM entspricht z.B. der Dezimalzahl 1900, da das C vor dem M von diesem abgezogen werden muss, also 1000 - 100 = 900 ergibt. MCM = M + (M - C) = 1000 + (1000 - 100) = 1900. Dezimalsystem und andere gebräuchliche Zahlensysteme In den anderen Zahlensystemen, die wir in der Informatik häufig verwenden (nämlich Dualsystem, Oktalsystem, Dezimalsystem und Hexadezimalsystem), stehen die Ziffern einer Zahl immer für einen Faktor, der mit der Wertigkeit seiner Stelle multipliziert wird. Die Dezimalzahl 123 steht für 1 * 100 + 2 * 10 + 3 * 1. Die Wertigkeit der Stelle ergibt sich aus ihrer Potenz mit der Basis des Zahlsystems. Die Basen der Zahlensysteme sind: Dual/Binär: 2 Oktal: 8 Dezimal: 10 Hexadezimal: 16 Nun werden die Stellen der Zahlen von rechts nach links beginnend mit 0 immer um 1 im Exponenten erhöht, um die Wertigkeit der Stelle zu berechnen. Beispiel im Dezimalsystem: 10 ^ 0 = 1 10 ^ 1 = 10 10 ^ 2 = 100 10 ^ 3 = 1.000 10 ^ 4 = 10.000 ... Dualsystem Im Dualsystem oder Binärsystem ist die Basis 2, die Wertigkeiten der Stellen der Zahlen lauten also: 2 ^ 0 = 1 2 ^ 1 = 2 2 ^ 2 = 4 2 ^ 3 = 8 2 ^ 4 = 16 2 ^ 5 = 32 ... Sie steigen also deutlich langsamer an als im Dezimalsystem. Mit jeder Stelle verdoppelt sich die Wertigkeit (im Vergleich zur Verzahnfachung im Dezimalsystem). Um den gleichen Zahlwert darstellen zu können, sind also deutlich mehr Ziffern nötig. Das wird noch deutlicher beim Hexadezimalsystem: Mit einer Ziffer können 16 verschiedene Werte dargestellt werden, also acht Mal so viele wie im Dualsystem. Beispiel: Die Dezimalzahl 256 wird im Hexadezimalsystem als 100 (1 * 256 + 0 * 16 + 0 * 1) notiert, aber im Dualsystem als 100000000, hat dort also dreimal so viele Ziffern. Im Dualsystem gibt es die Ziffern 0 und 1, die somit die "binary digits" (binäre Ziffern) darstellen. Abgekürzt wird daraus Bit (binary digit). Kombinationsmöglichkeiten Oft stellen wir uns die Frage, wie viele Kombinationsmöglichkeiten - also unterschiedliche Zahlen - es für eine gegebene Anzahl an Stellen geben kann. Im Dualsystem haben wir pro Stelle zwei Möglichkeiten: 0 und 1, also ein Bit. Für eine Zahl mit einer Stelle ergeben sich also zwei Möglichkeiten: 0 und 1. Für eine Zahl mit zwei Stellen verdoppelt sich die Anzahl der Möglichkeiten: 00 01 10 11 Und mit jeder weiteren Stelle verdoppeln sich die Möglichkeiten wieder, da vor jede bisherige Kombination wieder 0 oder 1 geschrieben werden kann: 000 001 010 011 100 101 110 111 Die Anzahl der Kombinationsmöglichkeiten oder unterschiedlichen Zahlen für eine gegebene Anzahl an Stellen lässt sich berechnen als Potenz aus Basis des Zahlsystems hoch der Stellenzahl. Für eine 5-stellige Dualzahl sind 2 ^ 5 = 32 Kombinationen möglich, für eine 3-stellige Oktalzahl 8 ^ 3 = 512. Beispiele für Zweierpotenzen Da in der IT das Dualsystem sehr wichtig ist - denn Computer können nur mit Nullen und Einsen rechnen - begegnen uns in der Praxis häufig immer wieder Zweierpotenzen, da die Basis des Zahlsystems nunmal 2 ist. Daher ist es wichtig, zumindest grob überschlagen zu können, wie viele Kombinationsmöglichkeiten es für eine gegebene Anzahl an Bits gibt. Ein paar wichtige Zweierpotenzen sollte man auch auswendig lernen, damit man nicht jedes Mal wieder nachrechnen muss: 8 Bit = 256 Möglichkeiten: ein Byte, Farbtiefe von GIF-Bildern, Größe eines RGB-Kanals, Länge der Codierung ISO-8859-1 16 Bit = 65.536 Möglichkeiten: Samplingtiefe bei CD-Qualität, Größe eines Netzwerkports, Länge eines Shorts 24 Bit = ca. 16,7 Mio. Möglichkeiten: Standardfarbtiefe von JPG- oder PNG-Dateien (ohne Alpha-Kanal) 32 Bit = ca. 4,3 Mrd. Möglichkeiten: Länge eines Integers, Länge einer IPv4-Adresse, lange Zeit die übliche Verarbeitungsbreite von CPUs 48 Bit (2 * 24 Bit = ca. 16,7 Mio. * 16,7 Mio. Möglichkeiten): Länge einer MAC-Adresse 64 Bit: Länge eines Longs, übliche Verarbeitungsbreite moderner CPUs 128 Bit: Länge einer IPv6-Adresse Zweierpotenzen im Vergleich Zum Abschluss habe ich hier noch eine Liste aller Zweierpotenzen bis 128 mit einigen Anwendungsfällen bzw. Namen. Die Beispiele passen natürlich nicht hundertprozentig (z.B. gibt es nicht exakt 2 ^ 33 Menschen auf der Erde und 2 ^ 20 ist nicht genau eine Million), aber vermitteln einen Eindruck ihrer Größe im Verhältnis zu den anderen Zahlen und helfen beim Überschlagen von Ergebnissen. 2 ^ 1 = 2: 1 Bit 2 ^ 2 = 4 2 ^ 3 = 8 2 ^ 4 = 16 2 ^ 5 = 32 2 ^ 6 = 64: BASE64 2 ^ 7 = 128: ASCII 2 ^ 8 = 256: Byte, ISO-8859-1, GIF-Farben 2 ^ 9 = 512 2 ^ 10 = 1.024 2 ^ 11 = 2.048 2 ^ 12 = 4.096 2 ^ 13 = 8.192 2 ^ 14 = 16.384 2 ^ 15 = 32.768 2 ^ 16 = 65.536: UTF-16, Samplingtiefe CD, Größe Netzwerkport 2 ^ 17 = 131.072 2 ^ 18 = 262.144 2 ^ 19 = 524.288 2 ^ 20 = 1.048.576: Million 2 ^ 21 = 2.097.152 2 ^ 22 = 4.194.304 2 ^ 23 = 8.388.608 2 ^ 24 = 16.777.216: Farbtiefe JPG 2 ^ 25 = 33.554.432 2 ^ 26 = 67.108.864 2 ^ 27 = 134.217.728 2 ^ 28 = 268.435.456 2 ^ 29 = 536.870.912 2 ^ 30 = 1.073.741.824: Milliarde 2 ^ 31 = 2.147.483.648 2 ^ 32 = 4.294.967.296: Farben + Alpha PNG, Integer, IPv4 2 ^ 33 = 8.589.934.592: Anzahl Menschen 2 ^ 34 = 17.179.869.184 2 ^ 35 = 34.359.738.368 2 ^ 36 = 68.719.476.736 2 ^ 37 = 137.438.953.472: Elon Musks Vermögen, Sterne in unserer Galaxie 2 ^ 38 = 274.877.906.944 2 ^ 39 = 549.755.813.888 2 ^ 40 = 1.099.511.627.776: Billion 2 ^ 41 = 2.199.023.255.552 2 ^ 42 = 4.398.046.511.104 2 ^ 43 = 8.796.093.022.208 2 ^ 44 = 17.592.186.044.416 2 ^ 45 = 35.184.372.088.832 2 ^ 46 = 70.368.744.177.664 2 ^ 47 = 140.737.488.355.328 2 ^ 48 = 281.474.976.710.656: MAC 2 ^ 49 = 562.949.953.421.312 2 ^ 50 = 1.125.899.906.842.620: Billiarde 2 ^ 51 = 2.251.799.813.685.250 2 ^ 52 = 4.503.599.627.370.500 2 ^ 53 = 9.007.199.254.740.990 2 ^ 54 = 18.014.398.509.482.000 2 ^ 55 = 36.028.797.018.964.000 2 ^ 56 = 72.057.594.037.927.900 2 ^ 57 = 144.115.188.075.856.000 2 ^ 58 = 288.230.376.151.712.000 2 ^ 59 = 576.460.752.303.423.000 2 ^ 60 = 1.152.921.504.606.850.000: Trillion 2 ^ 61 = 2.305.843.009.213.690.000 2 ^ 62 = 4.611.686.018.427.390.000 2 ^ 63 = 9.223.372.036.854.780.000 2 ^ 64 = 18.446.744.073.709.600.000: Long 2 ^ 65 = 36.893.488.147.419.100.000: Kombinationsmöglichkeiten Rubik's Cube 2 ^ 66 = 73.786.976.294.838.200.000 2 ^ 67 = 147.573.952.589.676.000.000 2 ^ 68 = 295.147.905.179.353.000.000 2 ^ 69 = 590.295.810.358.706.000.000: Quadratmillimeter Erdoberfläche 2 ^ 70 = 1.180.591.620.717.410.000.000: Trilliarde, Liter Wasser auf der Erde 2 ^ 71 = 2.361.183.241.434.820.000.000 2 ^ 72 = 4.722.366.482.869.650.000.000 2 ^ 73 = 9.444.732.965.739.290.000.000 2 ^ 74 = 18.889.465.931.478.600.000.000 2 ^ 75 = 37.778.931.862.957.200.000.000 2 ^ 76 = 75.557.863.725.914.300.000.000: Anzahl Sterne im sichtbaren Universum, Anzahl Sandkörner in der Sahara 2 ^ 77 = 151.115.727.451.829.000.000.000 2 ^ 78 = 302.231.454.903.657.000.000.000 2 ^ 79 = 604.462.909.807.315.000.000.000 2 ^ 80 = 1.208.925.819.614.630....

Um den Aufbau und den Ablauf der Abschlussprüfung in den IT-Berufen geht es in der einhundertachzigsten Episode des IT-Berufe-Pocasts. TL;DR Die gestreckte IHK-Abschlussprüfung besteht seit der Neuordnung 2020 aus Teil 1 nach etwa 18 Monaten und Teil 2 am Ende deiner Ausbildung. Teil 1 zählt 20 % deiner Abschlussnote; auf die betriebliche Projektarbeit entfallen 50 %, auf die beiden fachbezogenen Klausuren und Wirtschafts- und Sozialkunde jeweils 10 %. Für dein Projekt stehen dir einschließlich Dokumentation höchstens 40 Stunden zur Verfügung, als Fachinformatiker:in für Anwendungsentwicklung 80 Stunden. Ich empfehle dir, die Prüfung schon im ersten Ausbildungsjahr einzuplanen und die Vorgaben deiner IHK zu prüfen, weil sich Projektfristen und formale Anforderungen unterscheiden. Die Angaben gelten für die im Podcast beschriebenen Prüfungen außerhalb Baden-Württembergs. Kapitelmarken [00:00:00] Einführung: Die IHK-Abschlussprüfung seit der Neuordnung 2020 [00:02:08] Die Prüfung frühzeitig in deiner Ausbildung einplanen [00:02:45] IT-Berufe und gemeinsame Prüfungsbereiche [00:04:40] Sonderregeln in Baden-Württemberg [00:05:23] Ausbildungsverordnungen als verbindliche Grundlage [00:07:14] Gestreckte Abschlussprüfung und Gewicht von Teil 1 [00:08:17] Inhalte von Teil 1: Einrichten eines IT-gestützten Arbeitsplatzes [00:10:54] Aufgabenformat und Dauer von Teil 1 [00:11:32] Ausbildungsrahmenplan, Rahmenlehrplan und Lernlisten [00:14:26] Teil 2 und vorausgesetztes Wissen aus Teil 1 [00:16:22] Betriebliche Projektarbeit: Umfang und Anforderungen [00:17:43] Vorgaben deiner IHK für die Projektdokumentation [00:18:42] Dokumentation und Projektantrag [00:20:04] Freigabe, Zeitplanung und erlaubte Projektzeit [00:20:50] Projektpräsentation und Fachgespräch [00:22:39] Gewicht der Dokumentation und der mündlichen Prüfung [00:23:34] Die beiden fachbezogenen Klausuren [00:24:36] Prüfungsbereiche der einzelnen Berufe und Fachrichtungen [00:28:05] Wirtschafts- und Sozialkunde [00:29:19] Gewichte aller Prüfungsteile und eigenes Projektthema [00:31:14] Bedingungen zum Bestehen und Notenrechner [00:33:55] Schriftliche Prüfungstermine im Jahresverlauf [00:36:36] Newsletter passend zu deinen Prüfungsterminen [00:37:30] Ablauf bei einer dreijährigen Ausbildung [00:39:30] Projektfristen, Freigabe und Bearbeitungszeitraum [00:41:59] Dokumentation abgeben und schriftliche Prüfungen vorbereiten [00:42:45] Den mündlichen Termin vorbereiten [00:44:26] Ergebnisse, Bescheinigung und IHK-Zeugnis [00:45:43] Schriftliche Ergebnisse und mündliche Ergänzungsprüfung [00:47:20] Rückblick auf Aufbau und Ablauf der Abschlussprüfung [00:49:56] Weiterführende Unterlagen und Newsletter Inhalt Die Teile der Abschlussprüfung sollten allen Auszubildenden und Ausbilder:innen geläufig sein, da die drei Jahre der Ausbildung hauptsächlich auf diese Prüfung hinarbeiten. Der Aufbau der Abschlussprüfung ist für alle IT-Berufe identisch, die Inhalte unterscheiden sich aber natürlich. Insbesondere die Dauer und die Inhalte der Projektarbeit sind berufsspezifisch. Es gibt insgesamt 7 verschiedene IT-Berufe. Fachinformatiker:in Anwendungsentwicklung Systemintegration Daten- und Prozessanalyse Digitale Vernetzung IT-System-Elektroniker:in Kauf­mann/Kauffrau für Digitalisierungsmanagement Kaufmann/Kauffrau für IT-System-Management Der Großteil (60%) der Inhalte der schriftlichen Prüfung (GAP Teil 1 und WiSo) ist für alle Berufe gleich. Achtung: Die IHK-Prüfungen sind bundesweit einheitlich, aber in Baden-Württemberg laufen sie anders als in den übrigen 15 Bundesländern. Die folgenden Ausführungen gelten daher ggfs. nicht für Prüfungen in Baden-Württemberg. Aufbau der Abschlussprüfung Wer es ganz genau wissen will, schaut am besten in die jeweilige Berufsverordnung: Fachinformatiker:in Anwendungsentwicklung Fachinformatiker:in Systemintegration Fachinformatiker:in Daten- und Prozessanalyse Fachinformatiker:in Digitale Vernetzung IT-System-Elektroniker:in Kauf­mann/Kauffrau für Digitalisierungsmanagement Kaufmann/Kauffrau für IT-System-Management Die folgenden Zitate stammen aus der FIAusbV. Teil 1 (der gestreckten Abschlussprüfung) Teil 1 der gestreckten Abschlussprüfung findet im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes statt. Dieser Prüfungsteil ist für alle IT-Berufe identisch. Im Prüfungsbereich Einrichten eines IT-gestützten Arbeitsplatzes hat der Prüfling nachzuweisen, dass er in der Lage ist, 1. Kundenbedarfe zielgruppengerecht zu ermitteln, 2. Hard- und Software auszuwählen und ihre Beschaffung einzuleiten, 3. einen IT-Arbeitsplatz zu konfigurieren und zu testen und dabei die Bestimmungen und die betrieblichen Vorgaben zum Datenschutz, zur IT-Sicherheit und zur Qualitätssicherung einzuhalten, 4. Kunden und Kundinnen in die Nutzung des Arbeitsplatzes einzuweisen und 5. die Leistungserbringung zu kontrollieren und zu protokollieren. (FIAusbV §9 Abs. 2) Teil 1 der Prüfung ist eine schriftliche Prüfung über 90 Minuten, die nach 18 Monaten der Ausbildung absolviert werden muss. Inhalt sind alle im Ausbildungsrahmenplan (Teil der oben verlinkten Ausbildungsverordnung) und Rahmenlehrplan (für die Berufsschulen) bis zu diesem Zeitpunkt zu vermittelnden Inhalte. Rahmenlehrplan für die Ausbildungsberufe Fachinformatiker und Fachinformatikerin sowie IT-System-Elektroniker und IT-System-Elektronikerin Rahmenlehrplan für die Ausbildungsberufe Kaufmann für IT-System-Management, Kauffrau für IT-System-Management Kaufmann für Digitalisierungsmanagement sowie Kauffrau für Digitalisierungsmanagement Das Ergebnis des ersten Prüfungsteils geht zu 20% in die Abschlussnote ein. Tipps zur Vorbereitung auf die Prüfung gibt es in meinen entsprechenden Podcast-Episoden, z.B. Prüfungsvorbereitung auf Teil 1 der gestreckten Abschlussprüfung der IT-Berufe. Und hier habe ich eine große Liste mit allen potentiellen Prüfungsthemen für dich zusammengestellt: Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen. Teil 2 (der gestreckten Abschlussprüfung) In Teil 2 der Prüfung sollen die bereits in Teil 1 abgefragten Inhalte nicht explizit erneut abgefragt werden, sie werden aber als bekannt vorausgesetzt. Teil 2 der Prüfung teilt sich in vier konkrete Prüfungsteile auf: Projektarbeit Zwei fachspezifische schriftliche Prüfungen Wirtschaft- und Sozialkunde Betriebliche Projektarbeit Die betriebliche Projektarbeit ist in allen IT-Berufen durchzuführen. Sie unterscheidet sich aber je nach Beruf und Fachgebiet. Für die Umsetzung stehen 40 Stunden zur Verfügung, aber Anwendungsentwickler:innen haben 80 Stunden. Der Prüfling hat eine betriebliche Projektarbeit durchzuführen und mit praxisbezogenen Unterlagen zu dokumentieren. Vor der Durchführung der betrieblichen Projektarbeit hat er dem Prüfungsausschuss eine Projektbeschreibung zur Genehmigung vorzulegen. In der Projektbeschreibung hat er die Ausgangssituation und das Projektziel zu beschreiben und eine Zeitplanung aufzustellen. Die Prüfungszeit beträgt für die betriebliche Projektarbeit und für die Dokumentation mit praxisbezogenen Unterlagen höchstens 80 Stunden. (FIAusbV §12 Abs. 2) Zusätzlich zur Umsetzung der Projektarbeit und ihrer Dokumentation muss ein Prüfling in diesem Prüfungsteil nachweisen, dass er/sie in der Lage ist... die Arbeitsergebnisse adressatengerecht zu präsentieren und seine Vorgehensweise bei der Durchführung der betrieblichen Projektarbeit zu begründen (FIAusbV §12 Abs. 3) Das heißt, es werden eine Projektpräsentation und ein anschließendes Fachgespräch durchgeführt. Dabei gilt: Die Prüfungszeit beträgt insgesamt höchstens 30 Minuten. Die Präsentation soll höchstens 15 Minuten dauern. (FIAusbV §12 Abs. 3) Die Gewichtung der einzelnen Prüfungsteile sieht so aus: Projektdokumentation: 50% Projektpräsentation und Fachgespräch: 50% (nur eine gemeinsame Note ohne Unterscheidung der beiden Teile) Fachspezifische schriftliche Prüfung Dieser Prüfungsteil ist für alle IT-Berufe unterschiedlich und fachspezifisch. Es werden zwei schriftliche Prüfungen zu je 90 Minuten geschrieben. Die Themengebiete für die einzelnen Berufe sind: Fachinformatiker:in Anwendungsentwicklung Planen eines Softwareproduktes Entwicklung und Umsetzung von Algorithmen Fachinformatiker:in Systemintegration Konzeption und Administration von IT-Systemen Analyse und Entwicklung von Netzwerken Fachinformatiker:in Daten- und Prozessanalyse Durchführen einer Prozessanalyse Sicherstellen der Datenqualität Fachinformatiker:in Digitale Vernetzung Diagnose und Störungsbeseitigung in vernetzten Systemen Betrieb und Erweiterung von vernetzten Systemen IT-System-Elektroniker:in Installation von und Service an IT-Geräten, IT-Systemen und IT-Infrastrukturen Anbindung von Geräten, Systemen und Betriebsmitteln an die Stromversorgung Kauf­mann/Kauffrau für Digitalisierungsmanagement Entwicklung eines digitalen Geschäftsmodells Kaufmännische Unterstützungsprozesse Kaufmann/Kauffrau für IT-System-Management Einführen einer IT-Systemlösung Kaufmännische Unterstützungsprozesse Beide Prüfungen werden mit jeweils 10% in die Endnote eingerechnet. Die Aufgaben sind schriftlich zu beantworten und werden manuell von Prüfer:innen korrigiert. Wirtschaft- und Sozialkunde (WiSo) Im letzten Prüfungsteil soll der Prüfling nachweisen, dass er in der Lage ist... allgemeine wirtschaftliche und gesellschaftliche Zusammenhänge der Berufs- und Arbeitswelt darzustellen und zu beurteilen. (FIAusbV §15 Abs. 1) Diese schriftliche Prüfung dauert 60 Minuten und geht zu 10% in die Abschlussnote ein. Die Aufgaben sind durch Ankreuzen oder Eintragen von Zahlen zu beantworten und werden automatisiert korrigiert. Gewichtung der Prüfungsteile Die obigen Prüfungsteile gehen mit folgenden Gewichtungen in die Endnote ein (siehe FIAusbV §16 Abs. 1) Einrichten eines IT-gestützten Arbeitsplatzes (GAP Teil 1): 20% ...

Um das beliebte Prüfungsthema RAID geht es in der einhundertneunundsiebzigsten Episode des IT-Berufe-Podcasts. TL;DR Mit RAID fasst du mehrere Festplatten oder SSDs zu einem Verbund zusammen, dessen Eigenschaften vom RAID-Level abhängen. Redundante Daten sorgen dafür, dass dein System bei einem Festplattenausfall weiterlaufen kann; für Schäden am gesamten Verbund oder durch Ransomware brauchst du zusätzlich ein Backup. Für Teil 1 deiner Abschlussprüfung empfehle ich dir besonders RAID 0, 1 und 5 sowie RAID 01 und 10: Dazu gehören die verfügbare Kapazität und die Frage, welche Festplatten ausfallen dürfen. Auch wie schnell der Verbund liest und schreibt sowie der Aufwand beim Rebuild gehören zum Prüfungswissen. Kapitelmarken [00:00:00] Einführung und RAID als Prüfungsthema [00:02:11] Begriff und Grundprinzip von RAID [00:03:14] Verfügbarkeit und zusätzliche Datensicherung [00:07:20] Rebuild und Belastung der Festplatten [00:08:32] JBOD und einzeln angeschlossene Festplatten [00:09:26] Hardware-RAID und Software-RAID [00:11:42] Kriterien für die Prüfung und Nettokapazität [00:15:20] RAID 0: Striping und fehlende Redundanz [00:19:13] RAID 0: Lese- und Schreibgeschwindigkeit [00:20:29] RAID 0: Ausfallwahrscheinlichkeit und Einsatzgebiete [00:24:41] RAID 1: Mirroring und verfügbare Kapazität [00:27:11] RAID 1: Lesen und Schreiben [00:29:05] RAID 1 und Schutz durch Backups [00:30:52] RAID 5: Daten verteilen und Paritäten berechnen [00:34:21] RAID 5: Verteilte Paritäten [00:36:00] RAID 5: Geschwindigkeit und Nettokapazität [00:37:55] RAID 5: Ein Festplattenausfall und häufige Schreibzugriffe [00:41:13] RAID 2, 3 und 4 [00:44:07] RAID 6: Zwei Paritäten und Sicherheit beim Rebuild [00:47:41] RAID-Level kombinieren [00:49:02] Hierarchischer Aufbau und Legs [00:52:18] RAID 01 und RAID 10: Mindestanzahl und Kapazität [00:53:40] RAID 01: Aufbau und verkraftbare Ausfälle [00:56:09] RAID 01: Defekte erkennen und Rebuild [00:57:40] RAID 10: Aufbau und verkraftbare Ausfälle [00:59:07] RAID 10: Rebuild und Controller-Ausfälle [01:00:31] Diagramme und ergänzende Materialien [01:01:27] Prüfungswissen zu RAID [01:02:55] Newsletter zur IT-Ausbildung Inhalt RAID: Redundant Array of Independent Disks (bzw. früher "inexpensive" statt "independent) Idee: Mehrere Festplatten zu einem Verbund ("array") zusammenschließen Ziel: Ausfallsicherheit und höhere Verfügbarkeit (durch Einführung von Redundanz) Bei Ausfall einer Festplatte kann sie getauscht und das RAID-Array wiederhergestellt werden ("Rebuild"), in dieser Phase ist das RAID durch die hohe Belastung aber anfälliger für einen weiteren Festplattenausfall. RAID ersetzt nicht die Datensicherung. Lösung: Hardware- oder Software-RAID Hardware mit speziellen RAID-Controllern Software meist schon ins Betriebssystem eingebaut (z.B. in Linux) Alternative: JBOD (just a bunch of disks) Es gibt verschiedene RAID-Level Kriterien: Mindestanzahl Festplatten, Ausfallwahrscheinlichkeit, maximal verkraftbare ausgefallene Festplatten, Lese-/Schreibgeschwindigkeit, Nettokapazität RAID 0: Striping keine Redundanz, Merksatz: "0 Redundanz", "0 Sicherheit" mindestens 2 Festplatten nötig teilt Festplatten in gleich große Blöcke auf und verteilt die Daten darauf (stripes) Kapazität kann komplett genutzt werden dadurch kann schneller gelesen werden, da von mehreren Festplatten parallel gelesen wird auch das Schreiben geht schneller, da Daten parallel auf mehrere Festplatten geschrieben werden (aufgeteilt) fällt eine Festplatte aus, ist der gesamte Verbund defekt Ausfallwahrscheinlichkeit steigt, da Einzelwahrscheinlichkeiten multipliziert werden (z.B. bei 1% Ausfallwahrscheinlichkeit 2,97% gesamt) Einsatz: Streaming (viel Lesen, wenig Schreiben, Datenverlust verkraftbar bzw. anderweitig abgesichert), mehrere kleine zu einem großen Datenträger zusammenbauen Nachteil: hohe Ausfallwahrscheinlichkeit RAID 1: Mirroring komplette Redundanz, Merksatz: "1-zu-1-Kopie" mindestens 2 Festplatten nötig Daten werden auf allen Festplatten identisch abgelegt Kapazität wird halbiert oder gedrittelt usw. Lesegeschwindigkeit kann erhöht werden, indem Daten parallel von mehreren Festplatten gelesen werden Schreiben dauert länger, weil Daten auf mehrere Platten geschrieben werden müssen (Redundanz) Verbund fällt erst aus, wenn alle Festplatten ausfallen Ausfallwahrscheinlichkeit sinkt deutlich, z.B. bei 1% je Platte auf 0,0001% auch Mirroring ist keine Datensicherung, Viren werden sofort auf alle Platten geschrieben Einsatz: Hochverfügbarkeitssysteme Nachteil: geringe Nettokapazität RAID 5: Paritäten Teilredundanz durch Ablage von Paritätsinformationen mindestens 3 Festplatten nötig zusätzlich zu den auf mehrere Festplatten verteilten Daten werden auf allen Festplatten Paritätsinformationen (z.B. XOR) je Datenblock abgelegt Kapazität wird reduziert (z.B. 2/3 bei drei Festplatten) Lesegeschwindigkeit kann erhöht werden, indem Daten parallel von mehreren Festplatten gelesen werden Schreiben dauert durch Berechnung der Parität länger Verbund fällt erst aus, wenn zwei Festplatten defekt sind Ausfallwahrscheinlichkeit sinkt, z.B. bei 1% je Platte auf 0,0298% Nachteil: bei häufigen Schreibzugriffen durch Berechnung der Parität langsamer Irrelevante RAID-Level RAID 2: Striping mit Fehlerkorrektur, nur bei Großrechnern eingesetzt RAID 3/4: wie RAID 5 nur mit dedizierter Paritätsfestplatte (die dadurch stark belastet und zum Flaschenhals wird), bei RAID 3 wird auf Byte-Ebene und bei RAID 4 auf Block-Ebene gestript RAID 6: wie 5 nur mit doppelter Parität Kombinationen von RAID-Levels best of both worlds aus anderen RAID-Leveln immer von links nach rechts lesen und im Diagramm von unten nach oben: 01 -> zuerst werden zwei RAID 0 erstellt und dann zu einem RAID 1 zusammengebaut ein Leg ist das RAID-Array "unten" im Bild, aus dem das übergeordnete zusammengesetzt wird es werden mind. 4 Festplatten benötigt Kapazität wird halbiert Verbund verträgt zwei Festplattenausfälle, aber es ist wichtig, welche Platten ausfallen RAID 01 zwei Festplatten im gleichen Leg dürfen ausfallen es kann nicht erkannt werden, welche Festplatte im RAID 0 ausgefallen ist, da dann das gesamte Array defekt ist bei Ausfall einer Festplatte muss das gesamte Stripeset des Legs neu aufgebaut werden RAID 10 zwei Festplatten in unterschiedlichen Legs dürfen ausfallen bei Ausfall weniger Aufwand für Rebuild, weil nur im Leg gemirrort werden muss Achtung: auch der RAID-Controller kann ausfallen Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Datensicherung RAID Zusammenfassung Was RAID bedeutet Mehrere unabhängige Festplatten oder SSDs lassen sich zu einem gemeinsamen Verbund zusammenschalten. RAID steht für Redundant Array of Independent Disks. Je nach RAID-Level verteilt der Verbund die Daten auf seine Datenträger und hält zusätzliche Informationen vor, mit denen Daten bei einem Festplattenausfall erhalten bleiben. Wenn beispielsweise ein Webshop rund um die Uhr läuft, sollen seine Daten auch nach einem Festplattenausfall verfügbar bleiben. Du tauschst die defekte Festplatte aus, während das System weiterarbeitet. Der Verbund baut anschließend die Daten auf dem neuen Datenträger wieder auf. Für den Fall, dass ein Blitzeinschlag alle Festplatten beschädigt, brauchst du ein Backup. Dasselbe gilt bei Ransomware: Verschlüsselte Daten werden bei einer Spiegelung auf allen beteiligten Festplatten abgelegt. RAID und Backup gehören deshalb gemeinsam zum Schutz deiner Daten. Rebuild nach einem Festplattenausfall Nachdem du eine defekte Festplatte ersetzt hast, muss der Verbund die fehlenden Daten erneut aufbauen. Dieser Vorgang heißt Rebuild und kann Stunden oder Tage dauern. Dabei werden die verbliebenen Festplatten stark beansprucht, weil sie ihre Daten für den neuen Datenträger bereitstellen müssen. Gleichzeitig können weitere Lese- und Schreibzugriffe stattfinden. Fällt währenddessen eine weitere Festplatte aus, hängt es vom RAID-Level ab, ob die Daten weiterhin verfügbar bleiben. JBOD, Hardware-RAID und Software-RAID Wenn du mehrere Festplatten einzeln an einen Rechner anschließt, bezeichnet JBOD, also Just a Bunch of Disks, diese Zusammenstellung. Das Betriebssystem bindet die Datenträger unabhängig voneinander ein, etwa über Laufwerksbuchstaben unter Windows oder im Dateibaum unter Linux. Für einen RAID-Verbund gibt es zwei Wege: Hardware-RAID: Du schließt die Festplatten an einen RAID-Controller an und stellst dort das RAID-Level ein. Der Controller kann Berechnungen übernehmen und die CPU entlasten. Du musst ihn zusätzlich kaufen und bei möglichen Hardwareausfällen berücksichtigen, weil auch er ausfallen kann. Software-RAID: Software verwaltet den Verbund und führt die nötigen Berechnungen auf der CPU des Rechners aus. Dafür brauchst du keinen zusätzlichen RAID-Controller. Die CPU wird entsprechend belastet. Viele Betriebssysteme bringen passende Software bereits mit. Welche Eigenschaften du für die Prüfung kennen solltest Aus meinen Prüfungskorrekturen kenne ich Schwierigkeiten beim Thema RAID. Für deine Vorbereitung empfehle ich dir, jedes relevante Level anhand dieser Fragen durchzugehen: Wie viele Festplatten brauchst du mindestens? Wie verändert sich die Wahrscheinlichkeit, dass der Verbund ausfällt? Welche und wie viele Festplatten dürfen ausfallen, während die Daten verfügbar bleiben? Wie wirkt sich das Level auf die Lesegeschwindigkeit aus? Wie schnell kann der Verbund schreiben? Wie viel Speicherplatz steht dir als Nettokapazität zur Verfügung? Die Nettokapazität lässt sich in schriftlichen Prüfungen berechnen. Speicherplatz, auf dem redundante Informationen liegen, steht für weitere Daten entsprechend nicht zur Verfügung. RAID 0: Striping Bei RAID 0 werden Daten blockweise über mindestens zwei Festplatten verteilt. Zusammengehörige Blöcke bilden einen Stripe, also einen Streifen über die beteiligten Datenträger. Eine größere Datei liegt dadurch in Teilen auf mehreren Festplatten. ...

Um das beliebte Prüfungsthema Datensicherung geht es in der einhundertachtundsiebzigsten Episode des IT-Berufe-Podcasts. TL;DR Datensicherung schützt deine Daten vor Verlust, indem du sie auf weiteren Medien speicherst und das Zurückspielen testest. Für dich als IT-Azubi gehören dazu die verschiedenen Backup-Arten, passende Speichermedien und das Generationenprinzip, die auch in Teil 1 der gestreckten Abschlussprüfung vorkommen können. Welche Daten du wie oft sicherst, hängt davon ab, wie schnell du sie wieder brauchst und welche Folgen ein Verlust hätte. Mein privates Konzept umfasst ein NAS und externe Festplatten, von denen eine verschlüsselt außerhalb meines Hauses liegt; ausgewählte Daten sichere ich zusätzlich auf meinem eigenen Server. Kapitelmarken [00:00:00] Datensicherung für Prüfung und Praxis [00:02:20] Datenschutz, Datensicherheit und Datensicherung [00:05:31] Ursachen für Datenverlust [00:09:35] Folgen für Unternehmen und private Daten [00:12:01] Mitarbeiter:innen schulen und Dateien sicher speichern [00:15:39] Welche Daten gehören ins Backup? [00:18:38] Daten archivieren und sichern [00:20:19] Das Zurückspielen testen [00:21:48] Geänderte Dateien erkennen [00:24:19] Das Änderungsdatum im Dateisystem [00:26:00] Das Archiv-Bit [00:27:36] Änderungen mit Hashwerten erkennen [00:29:05] Backup-Arten und ihre Anforderungen [00:30:06] Voll-Backup [00:31:44] Differenzielles Backup [00:32:54] Inkrementelles Backup [00:34:22] Begriffe merken und Wochenbeispiel durchgehen [00:36:51] Kriterien für Backup-Medien [00:42:12] Magnetbänder [00:43:43] Mechanische Festplatten [00:45:08] SSDs und USB-Sticks [00:46:34] Optische Speichermedien [00:48:12] Cloud-Speicher [00:51:08] Mehrere Backup-Medien und Rotation [00:55:18] Das Generationenprinzip [01:00:34] Cold-Backup und Hot-Backup [01:04:49] Mein privates Backup-Konzept [01:05:57] Persönliche Dateien und Programme [01:07:29] Kopie auf dem lokalen NAS [01:09:13] Externe Festplatte vom Stromnetz trennen [01:10:09] Eine Kopie außer Haus lagern [01:10:49] Wie häufig sichere ich meine Daten? [01:12:09] Eigener Server und verschlüsselte Kopien [01:13:23] SyncToy als Backup-Software [01:14:23] Fotos auch unterwegs sichern Inhalt Datensicherung ist quasi das deutsche Wort für Backup und behandelt das Sichern und Wiederherstellen von Daten auf Sicherungsmedien wie Magnetbändern, externen Festplatten oder der Cloud. Es geht hierbei um den Schutz vor Datenverlust. Abgrenzung von Datensicherung, Datensicherheit und Datenschutz. Siehe auch Datenschutz vs. Datensicherheit vs. Datensicherung. Die Datensicherung ist ein Teil der Datensicherheit, der sich um das Schutzziel Verfügbarkeit kümmert. Warum können Daten verloren gehen? Hardwaredefekte, Probleme im Stromnetz, Feuer/Wasser, Naturkatastrophen, menschliches Versagen oder Vorsatz (z.B. absichtliches Löschen oder Diebstahl), Ransomware Ein Datenverlust kann für Unternehmen (aber auch Privatpersonen) große negative Auswirkungen haben. In schlimmen Fällen kann das Unternehmen nicht weiter arbeiten und muss Insolvenz anmelden. Mitarbeiter sollten zum Thema Datenverlust sensibilisiert werden. Was sind die Konsequenzen eines Datenverlustes für das Unternehmen und die Person selbst? Dateien sofort abspeichern und nicht erst nach stundenlanger Arbeit. Dateien regelmäßig speichern. Nicht nur auf der eigenen Festplatte speichern, sondern im Netzwerk. Was sind sicherungswürdige Daten? Daten, die man nicht ohne Weiteres wiederbeschaffen kann (z.B. selbst erstellte Dateien, Fotos, Dokumente, Arbeitsergebnisse). Meist werden Betriebssystemdaten und Programminstallationen nicht gesichert. Grundsätzlich kommt es darauf an, wie schnell Daten wiederhergestellt werden können müssen. Auch das Betriebssystem kann daher gesichert werden müssen, wenn eine Neuinstallation zu lange dauern würde. Es gibt auch gesetzliche Aufbewahrungsfristen für Daten, aber bitte nicht mit Archivierung durcheinanderbringen. Wichtig bei der Datensicherung: auch die Datenwiederherstellung testen! Wie erkennt die Software, welche Daten zu sichern sind? Metadaten wie letztes Änderungsdatum, Archiv-Flag oder Dateihash. Wie viele Daten werden gesichert und wie lange dauert die Wiederherstellung? Trade Off zwischen geringem Speicherverbrauch bzw. langer Backuplaufzeit und schneller Wiederherstellungsdauer. Unterschiedliche Verfahren: Vollbackup (alle Daten sichern), differenzielles Backup (nur geänderte Daten zum letzten Vollbackup werden gesichert) und inkrementelles Backup (geänderte Daten zum letzten Voll- oder inkrementellen Backup werden gesichert). Vollbackup: Viel Speicherverbrauch, lange Backuplaufzeit, schnelle Wiederherstellung (nur 1 Backup nötig). Differenzielles Backup: Mittelweg zwischen Speicherverbrauch/Backuplaufzeit und Wiederherstellung (2 Backups nötig). Inkrementelles Backup: Geringster Speicherverbrauch, aber längste Wiederherstellung (z.B. 5 Backups nötig). Backup-Medien Kriterien bei der Auswahl von Backupmedien: Kapazität, Transferrate, Zugriffsgeschwindigkeit, Kosten, Lebensdauer, Störanfälligkeit Mögliche Medien: Magnetbänder, Festplatten/HDDs, SSDs, USB-Sticks, CDs/DVDs/BluRays, Cloud Generationenprinzip bzw. Großvater/Vater/Sohn Auch Backup-Medien können kaputt gehen! Nur ein einziges Medium zu nutzen, ist daher nicht zu empfehlen. Außerdem würden neue Sicherungen die alten überschreiben, enthalten aber ggfs. früher gelöschte Daten nicht mehr für eine spätere Wiederherstellung. Zu viele Medien kosten aber unverhältnismäßig viel Geld. Daher ist ein Mittelweg nötig: ein Rotationsprinzip. "Übliche" Medien bei 5-Tage-Woche: 4 x Sohn (Mo - Do), 4 x Vater (Fr), 12 x Großvater (Monat) Hot/Cold Backup Cold-Backup: Herunterfahren der zu sichernden Systeme nötig. Einfach, aber mit Downtime verbunden. Hot-Backup: Systeme werden während des Betriebs gesichert. Schwierig (z.B. Redo-Logs bei Datenbanken), aber keine Downtime nötig. Mein privates Backup-Konzept Nur eigene Dateien sichern, keine Betriebssystemdaten oder Programme. Schritt 1: NAS* am lokalen Netzwerk. Schritt 2: externe Festplatte* ohne Netzwerk/Strom. Schritt 3: externe Festplatte außerhalb des Hauses. Bestimmte Daten zum schnellen/einheitlichen Zugriff verschlüsselt in der (eigenen) Cloud. Produktempfehlungen Ich verwende seit Jahren die externen Festplatten von Western Digital* für meine privaten (!) Backups. Sie sind relativ günstig und benötigen lediglich einen USB-Anschluss am PC. Sie sind sehr klein und kompakt und auch recht leicht. * Zusammen mit einer praktischen Trage- und Schutztasche* kann man sie gut für Außer-Haus-Sicherungen nutzen. Dafür solltest du die Daten dann aber verschlüsseln, z.B. mit Bitlocker. * Für die schnelle Ad-hoc-Datensicherung zwischendurch nutze ich - ebenfalls seit einigen Jahren - ein NAS von Synology*. Das hat neben der Datensicherungsfunktion auch noch einen Haufen anderer Funktionen, wie z.B. Streamingserver für Multimedia, Webserver und viele weitere. * Zum Kopieren der Dateien nutze ich keine spezielle Backup-Software, sondern das kostenfreie SyncToy von Microsoft. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Externe Festplatte* für die private Datensicherung. NAS von Synology* für die schnelle Datensicherung im lokalen Netzwerk. Generationenprinzip Oracle Database Hot Backup and Recovery BitLocker SyncToy Zusammenfassung Datensicherung als Thema für IT-Azubis In meiner Prüfungsvorbereitung gehört Backup zum Bereich IT-Security. Das Thema betrifft alle IT-Berufe und begegnet dir auch im Unternehmen sowie bei deinen privaten Dateien. Die Begriffe Datenschutz schützt personenbezogene Daten natürlicher Personen vor Missbrauch durch Dritte. Dazu gehören etwa Namen und Anschriften sowie besonders schützenswerte Angaben zu Krankheiten. Rechtliche Grundlagen sind die DSGVO und das Bundesdatenschutzgesetz. Datensicherheit umfasst den Schutz sämtlicher Daten. Ihre Schutzziele sind Authentizität, Verfügbarkeit, Vertraulichkeit und Integrität. Datensicherung, auch Backup genannt, schützt vor Datenverlust und gehört zur Datensicherheit. Sie trägt zum Schutzziel Verfügbarkeit bei, weil du verlorene Daten aus einer zusätzlichen Kopie zurückspielen kannst. Wie Daten verloren gehen Wenn du dein Backup planst, beziehen sich die Schutzmaßnahmen auf konkrete Gefahren: Hardware kann ausfallen, etwa durch Verschleiß einer mechanischen Festplatte. Überspannung kann mehrere Geräte im selben Stromnetz gleichzeitig beschädigen. Feuer, Flüssigkeiten und Naturkatastrophen können Datenträger oder ganze Gebäude zerstören. Menschen löschen Dateien versehentlich oder beschädigen Daten absichtlich. Ransomware verschlüsselt Daten und verhindert den Zugriff. Ein gestohlener oder heruntergefallener Laptop kann ebenfalls dazu führen, dass deine Dateien verloren gehen. Ein Backup-Medium am selben Stromnetz ist bei Überspannung mitbetroffen. Liegt es im selben Gebäude, kann ein Brand auch diese Kopie zerstören. Daraus ergibt sich, wo du deine zusätzlichen Datenträger aufbewahrst und wann du sie anschließt. In meinem Unternehmen, einer Krankenversicherung, bilden Daten die Grundlage der täglichen Arbeit. Gehen langjährige Datenbestände verloren, kann das den Betrieb zum Stillstand bringen und bis zur Insolvenz führen. Privat betrifft ein Verlust beispielsweise eingescannte Steuerunterlagen oder Fotos, die du erneut aufnehmen müsstest. Mitarbeiter:innen schulen und Dateien sicher speichern Als IT-Fachkraft gehört es zu deinen Aufgaben, Mitarbeiter:innen den sicheren Umgang mit Dateien beizubringen. Schulungen vermitteln, welche Folgen ein Datenverlust hat und wie sich Fehler vermeiden lassen. Speichere ein neues Dokument frühzeitig und während der Arbeit regelmäßig. In meiner Praxis gingen einmal drei Stunden Arbeit an einer Word-Datei verloren, weil sie bis zum Absturz ausschließlich im Arbeitsspeicher lag. Auch sehr lange Dateinamen und Pfade können Probleme verursachen,...

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. TL;DR Aus meinen Fachgesprächen der Sommerprüfung 2022 für Fachinformatiker:innen Anwendungsentwicklung habe ich häufige Fragen zusammengestellt, mit denen du dich auf deine Prüfung vorbereiten kannst. Dabei spielen wirtschaftliche Themen wie Stundensatz und laufende Projektkosten ebenso eine Rolle wie technische Grundlagen. Alles, was du in deinem Projekt einsetzt, solltest du erklären und begründen können, möglichst mit Beispielen aus deinem eigenen Code. Welche Fragen dir dein Prüfungsausschuss stellt, hängt von deinem Projekt und den beteiligten Prüfer:innen ab. Kapitelmarken [00:00:01] Informationen zum Fachgespräch [00:00:37] Rückblick auf die Fachgespräche der Sommerprüfung 2022 [00:02:17] Eigene Prüfungserfahrungen und projektbezogene Fragen [00:03:15] Häufig falsch beantwortete Themen [00:04:17] Wirtschaftswissen und die Technologien deines Projekts [00:07:30] Bestandteile des Stundensatzes [00:08:31] Sozialversicherung und Beiträge des Unternehmens [00:10:33] Normalformen in Datenbanken [00:11:58] Kapselung und Sichtbarkeitsmodifizierer [00:13:06] Klassen und Objekte [00:14:35] Lambda-Ausdrücke [00:15:50] Vererbung [00:16:43] Polymorphie und dynamisches Binden [00:19:02] Datenbankanomalien [00:21:06] Einfügeanomalie anhand von Bestellungen [00:22:08] Löschanomalie und getrennte Tabellen [00:23:14] Kardinalitäten und passende Beispiele [00:25:32] Statische, dynamische, starke und schwache Typisierung [00:28:08] Generische Klassen [00:29:24] REST-APIs absichern und OAuth [00:31:35] Softwarequalität [00:32:33] Kostenarten und Gemeinkostenzuschläge [00:35:32] Hashverfahren und Kollisionen [00:37:32] Laufende Kosten des Projekts [00:38:19] Lohn, Gehalt und Ausbildungsvergütung [00:39:49] Architekturmodelle wie MVC [00:40:58] Redundante Daten [00:41:20] REST als Architekturprinzip [00:42:29] Scrum und agile Grundlagen [00:42:58] Betriebsabrechnungsbogen [00:44:29] Lastenheft und Pflichtenheft [00:45:07] Referenzielle Integrität [00:46:08] Signatur einer Methode [00:47:48] Testverfahren [00:48:38] Datenbanktransaktionen und ACID [00:50:35] Asynchron programmieren mit async und await [00:52:11] Fehlerarten beim Programmieren [00:53:37] HTTP-Statuscodes und Methoden [00:55:53] Kanban und Work-in-Progress-Limits [00:57:48] Exception Handling und finally [00:58:41] Abschreibungen [01:00:09] Datenschutz und personenbezogene Daten [01:01:15] Variablen in JavaScript mit var, let und const [01:02:29] Weitere Materialien und Hilfe durch dein:e Ausbilder:in [01:03:55] Newsletter und Feedback zu Prüfungserfahrungen Inhalt Fachgespräche Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung) Disclaimer: Meine Erfahrungen aus den Prüfungen, an denen ich beteiligt war, ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland. Viele der genannten Themen für das Fachgespräch gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben (insb. die wirtschaftlichen Themen). Fast immer falsch beantwortet wurden Fragen nach Stundensatz, laufenden Kosten, Lösch-Anomalie, Lambda-Ausdrücken, generischen Klassen. Häufige Fragen im Fachgespräch Das hier ist meine Liste mit den häufigsten Fragen im Fachgespräch für Fachinformatiker:innen Anwendungsentwicklung, absteigend nach Anzahl sortiert. Man erkennt deutlich, dass unter der Top-Themen sehr viele Wirtschaftsthemen sind, weil viele "Techniker:innen" diesen Bereich bei der Prüfungsvorbereitung vernachlässigen und dementsprechend in Projektdokumentation und Projektpräsentation falsch machen, was dann entsprechende Fragen im Fachgespräch provoziert. Viele der anderen Themen ergeben sich aus Technologien, die die Prüflinge selbst eingesetzt haben. Ich sage immer wieder: Alles, was man benutzt (oder in der Projektpräsentation erwähnt), muss man auch erklären können. Da viele Projekte aktuell als Single-Page-Application in JavaScript mit einer anderen Programmiersprache im Backend (z.B. Java) umgesetzt werden, kommen z.B. Fragen nach REST, OAuth, Typisierung und JavaScript-Spefizika immer öfter vor. Stundensatz (15) Fast immer falsch berechnet (nur Brutto-Ausbildungsvergütung enthalten). Normalisierung (13) Oft nicht sauber mit Fachbegriffen erklärt. Sozialversicherung (13) Viele kennen den Arbeitgeberanteil nicht. Kapselung (11) Getter/Setter, Sichtbarkeitsmodifizierer usw. Klasse vs. Objekt (11) "Ein Objekt ist ein Teil einer Klasse" usw. Lambda-Ausdrücke (11) Werden ständig genutzt, aber nur sehr wenige Prüflinge können sie erklären. Vererbung (10) Wir insb. in Frameworks häufig benötigt, aber zu den Details fehlen häufig Kenntnisse. Anomalien (Einfüge-/Änderungs-/Löschanomalie) (9) Die Löschanomalie wurde dieses Jahr nicht einmal korrekt erklärt. Einzel- vs. Gemeinkosten (9) Viele Prüflinge haben offensichtlich noch nie etwas von einem Kostenträger gehört. Polymorphie (9) Viele Prüflinge werfen das mit Vererbung durcheinander und können es nicht sauber abgrenzen. Kardinalitäten (8) Dieses Thema haben die meisten Prüflinge gut beantwortet, aber teilweise mit seltsamen Beispielen. Typisierung (8) Die wenigsten Prüflinge können statisch/dynamisch und vor allem stark/schwach abgrenzen. Generische Klassen (7) Sauber erklären können das die wenigsten Prüflinge. OAuth (6) REST-APIs werden heute offensichtlich ohne jegliche Absicherung erstellt. Softwarequalität (6) Die gute alte (und neue) ISO-Norm ist nur wenigen Prüflingen bekannt. fixe vs. variable Kosten (5) Sie werden oft mit Einzel-/Gemeinkosten verwechselt. Hashverfahren (5) Die Eigenschaften eines guten Hashverfahrens können die wenigsten Prüflinge nennen, wissen aber wenigstens, wofür man sie braucht. laufende Kosten (5) In vielen Projekten gibt es keine (!) laufenden Kosten. Lohn vs. Gehalt (5) Und natürlich darf auch die Ausbildungsvergütung nicht fehlen! MVC/MVVM/MVP usw. (5) Die Architektur der eigenen Anwendung sollte man erklären und auch von Alternativen abgrenzen können. Redundanzen (5) Der Feind jedes Datenbankmodellierers. Wird häufig richtig erklärt. REST (5) Jeder nutzt es, kaum jemand kann es korrekt erklären. Scrum (5) Quasi Grundwissen für alle IT-Berufe. Betriebsabrechnungsbogen (4) Oft eine Anschlussfrage bei Einzel-/Gemeinkosten. Lastenheft/Pflichtenheft (4) Viele Prüflinge verwechseln die Begriffe oder vergessen, dass das Pflichtenheft Vertragsbestandteil ist. referentielle Integrität (4) Wird oft mit Redundanz durcheinander gebracht. Signatur (4) Viele Prüflinge zählen die Sichtbarkeit, den Rückgabewert, static usw. mit zur Signatur. Testverfahren (4) Es gibt soooo viele Testverfahren, aber meist sind nur Black- und White-Box-Test bekannt. Transaktionen (4) Ja, auch die ACID-Kriterien darf man kennen. async/await (3) Wenn man es benutzt, muss man es erklären können. Auch inkl. der technischen Umsetzung in der gewählten Programmiersprache. Fehlerarten bei der Programmierung (3) Compile-Fehler, semantische Fehler, Laufzeitfehler usw. sollte man auseinanderhalten können. HTTP-Methoden (3) Ganz oft werden POST, PUT und PATCH verwechselt. Kanban (3) Für viele Prüflinge besteht der Prozess nur aus dem Kanban-Board. try/catch (3) Das können die meisten Prüflinge erklären. Abschreibungen (2) Meist eine Folgefrage zu Einzel-/Gemeinkosten. Mit ein wenig Hilfe kommen die meisten Prüflinge darauf. Datenschutz (2) Traurig, wie wenige Prüflinge das sauber erklären und von Datensicherheit abgrenzen können. let/var/const in JavaScript (2) Ein zentrales Feature von JavaScript, das auch häufig in Code-Beispielen der Prüflinge verwendet wird. Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Zusammensetzung des Stundensatzes - Häufige Fragen im Fachgespräch Normalisierung - Häufige Fragen im Fachgespräch Erläuterung der Gehaltsabrechnung - Häufige Fragen im Fachgespräch Häufige Fragen im Fachgespräch - Kapselung Einführung in die Programmierung und Objektorientierung Häufige Fragen im Fachgespräch - Vererbung Häufige Fragen im Fachgespräch - Polymorphie Kryptographie - Hashverfahren und elektronische Signatur Scrum Lasten- und Pflichtenheft in der Projektdokumentation Algorithmen und Methoden (Lernzielkontrolle) Testverfahren für Software - Häufige Fragen im Fachgespräch Datenschutz vs. Datensicherheit vs. Datensicherung Zusammenfassung Welche Fragen im Fachgespräch vorkommen Für meinen Rückblick auf die Sommerprüfung 2022 habe ich die Fragen aus den Fachgesprächen festgehalten, an denen ich als Prüfer beteiligt war. Die Liste enthält Themen, die mindestens zweimal vorkamen. Sie richtet sich vor allem an dich als IT-Azubi zum/zur Fachinformatiker:in Anwendungsentwicklung; wirtschaftliche Fragen betreffen auch andere IT-Berufe. Die Häufigkeiten stammen aus meinen eigenen Prüfungen. Dein Prüfungsausschuss kann andere Schwerpunkte setzen. Häufig beginnt das Fachgespräch mit deinem Abschlussprojekt, bevor allgemeinere Fragen folgen. Wenn du dich vorbereitest, beschäftige dich mit den Technologien und Entscheidungen in deinem Projekt. Dazu gehört, dass du Eigenschaften deiner Programmiersprachen erklären und deine Architektur begründen kannst. Bei einer Single-Page-Application können etwa Fragen zu Alternativen und zu ihren Vor- und Nachteilen folgen. Beispiele aus deinem Projekt helfen dir dabei, dein Wissen verständlich zu zeigen. Besonders häufig blieben Antworten zu folgenden Themen falsch oder unvollständig: Bestandteile des Stundensatzes Laufende Kosten des Projekts Löschanomalien in Datenbanken Lambda-Ausdrücke Generische Klassen Wirtschaftliche Fragen Stundensatz und Sozialversicherung In meinen Prüfungen wurde fast in jedem Fachgespräch nach dem Stundensatz gefragt....

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. TL;DR Aus meinen Erfahrungen mit den Projektpräsentationen der Sommerprüfung 2022 gebe ich dir Hinweise für deine eigene Prüfung als Fachinformatiker:in Anwendungsentwicklung. In 15 Minuten sollte verständlich werden, welches Problem du gelöst hast und wie du dabei vorgegangen bist. Zeige deine Arbeit mit passenden Diagrammen und ausgewählten Codebeispielen, wobei auch die Wirtschaftlichkeit und die Qualität deines Ergebnisses erkennbar werden müssen. Gut lesbare Folien und ein geübter, frei gesprochener Vortrag helfen dir dabei, deine Leistung für den Prüfungsausschuss sichtbar zu machen. Kapitelmarken [00:00:00] Rückblick auf die Projektpräsentationen der Sommerprüfung 2022 [00:01:13] Vorbereitung und Bewertung der Präsentation [00:05:33] Inhalte visualisieren und Stichpunkte schrittweise einblenden [00:07:40] Kopfzeilen und lesbare Schriftgrößen [00:08:50] Projektbezogene Bilder und Screenshots [00:11:04] Eigene Folien statt austauschbarer Firmenvorlagen [00:12:58] Lesbarkeit und Rechtschreibung prüfen [00:15:59] Diagramme farblich passend gestalten [00:18:48] Einstieg und persönliche Vorstellung [00:20:09] Präsentationen mit LaTeX erstellen [00:21:27] Code zeigen und direkt auf der Folie hervorheben [00:23:16] Bilder und Humor ohne zusätzliche Meta-Erklärungen [00:26:59] Medienwechsel und Zeichnungen an der Tafel [00:29:06] Frei sprechen und Blickkontakt halten [00:31:25] Präsentation als eigenständige Prüfungsleistung [00:34:39] Inhalte visualisieren und Arbeitsergebnisse belegen [00:37:10] Codebeispiele auf der passenden Abstraktionsebene [00:39:36] Problem und Projektziel verständlich darstellen [00:41:36] Bibliotheken und Versionsnummern angemessen behandeln [00:43:41] Technologien anhand ihres Einsatzes im Projekt begründen [00:46:49] Entwicklungsprozesse und Scrum knapp vorstellen [00:48:28] Entwicklungswerkzeuge und Deployment per FTP [00:51:16] Respektvolle Anrede des Prüfungsausschusses [00:53:04] Anschlüsse und Technik für die Prüfung vorbereiten [00:54:55] Programmablaufpläne und UML-Diagramme [00:56:04] Englische Begriffe und verständliche Namen im Code [00:59:15] Mögliche Inhalte einer Projektpräsentation [01:00:03] Projektplanung und Wirtschaftlichkeit [01:00:26] Projektziel und Anforderungen [01:00:47] Architektur und eingesetzte Technologien [01:01:10] Code und Datenmodelle [01:01:43] Tests und Oberflächenentwürfe [01:02:14] Qualität des Codes sichern [01:02:46] Dokumente und fertige Anwendung zeigen [01:03:16] Soll-Ist-Vergleich und persönliche Erfahrungen [01:03:52] Ausblick auf den weiteren Projektverlauf [01:04:24] Hinweise zur Vorbereitung und weitere Angebote Inhalt Projektpräsentationen Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung) Disclaimer: Meine Meinung ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland. Ich schaue insbesondere auf die Gestaltung der Folien und den Vortrag, aber wichtig sind natürlich auch die fachlichen/technischen Inhalte der Präsentation. Einzelne Punkte auf der folgenden Liste führen nicht zwangsläufig zu Punktabzug bei der Note, aber oft treten mehrere Punkte gemeinsam auf, was dann einen Punktabzug rechtfertigt. Viele "Probleme" mit den Projektpräsentationen gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben. Foliengestaltung und Vortrag Oft wurden Punktlisten nicht Schritt-für-Schritt eingeblendet, sondern sofort als Ganzes gezeigt. (Unnötige) Kopfzeile in einer Präsentation war winzig klein. Cliparts für die Darstellung des Ist-Zustands, anstatt eigene Fotos zu machen. Präsentationen vom selben Unternehmen sahen fast identisch aus und hatten auch einen sehr ähnlichen Aufbau. Der Text auf den Folien war oft sehr klein und kaum lesbar. (Offensichtliche) Rechtschreibfehler auf den Folien. Tortendiagramme sahen in fast allen Präsentationen identisch aus (Standardfarben von PowerPoint genutzt). Vorstellung des Prüflings: graue Silhouette statt Bild verwendet. Präsentation mit LaTeX erstellt, aber leider ausschließlich Textfolien. Code wurde durch Zeigen an der Leinwand erklärt, anstatt ihn visuell hervorzuheben. Prüfling kommentierte die Vorstellung des Unternehmens mit "hier habe ich mal statt des klassischen Bildes unsere Azubis genommen". Ein Prüfling hat die Architektur seiner Anwendung an die Tafel gezeichnet. Einige Prüflinge haben stark abgelesen und kaum Blickkontakt zum Prüfungsausschuss gehabt. Fehlende/unnötige Inhalte Oft wurden die Artefakte aus der Projektdokumentation nicht in der Projektpräsentation gezeigt. Oft werden Inhalte genannt, aber nicht visualisiert (z.B. 3-Schichten-Architektur ohne Grafik). Angeblich erstellte Artefakte werden erwähnt, aber nicht gezeigt. Teilweise wurde viel zu detailliert auf Code eingegangen. Das Ziel des Projekts wird oft nicht deutlich. Jedes genutzt JavaScript-Package wurde inkl. Versionsnummer aufgeführt und erklärt. Ein Prüfling hat jede verwendete Technologie ausführlich erklärt (z.B. Kafka und Kubernetes). Scrum wurde in einer Präsentation ausführlich erklärt. Sonstiges Notepad++ als IDE verwendet. Deployment als Upload auf einen FTP-Server. Einige Prüflinge haben den Prüfungsausschuss geduzt. Prüfling mit Mac hatte keinen Adapter für HDMI dabei. Prüfling hat einen Programmablaufplan erstellt, anstatt ein UML-Diagramm zu nutzen. Einige Unternehmen entwickeln wohl auf Englisch, aber niemand schaut auf die korrekten Vokabeln. Mögliche/erwartete Artefakte Die folgenden Artefakte sind in einer Projektpräsentation möglich bzw. ich würde sie in einer "sehr guten" Arbeit erwarten. Auch hier gilt: Wenn mal eines oder mehrere der Artefakte fehlen, heißt das nicht automatisch, dass eine schlechte Note folgt. Es geht immer auch um den Gesamteindruck der Präsentation inkl. Gestik, Mimik usw. Projektplanung: Zeitplanung, Ressourcen, Entwicklungsprozess, Kosten, Amortisation Ziel des Projekts: Use-Case-Diagramm, Aktivitätsdiagramm, Lasten-/Pflichtenheft, ereignisgesteuerte Prozesskette Architektur: Komponentendiagramm Technologien: Programmiersprache, Frameworks Implementierung: Source Code, Klassendiagramm, Sequenzdiagramm Datenmodellierung: Entity-Relationship-Modell, Tabellenmodell Test: Source Code, Testprotokoll User Interface: Mockups Qualitätssicherung: Code-Reviews, Entwicklungsprozess, statische Codeanalyse, CI/CD Dokumentation: Entwickler-/Kundendokumentation Ergebnis des Projekts: Screenshots Fazit: Soll-/Ist-Vergleich, Abnahme, Lessons Learned, Ausblick Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Cliparts werten die Folien auf! - Mythen der Projektpräsentation Foliennummern bzw. Seitenzahlen gehören auf jede Folie! - Mythen der Projektpräsentation Corporate Design ist Pflicht - Mythen der Projektpräsentation Sourcecode gehört nicht in die Präsentation - Mythen der Projektpräsentation Technische Inhalte kann man nicht mit Bildern illustrieren - Mythen der Projektpräsentation Inhalte der Projektpräsentation Zusammenfassung Meine Erfahrungen aus der Sommerprüfung 2022 Für deine Projektpräsentation als IT-Azubi habe ich Hinweise aus den Prüfungen zusammengestellt, an denen ich im Sommer 2022 als Prüfer beteiligt war. Die Beispiele stammen aus der Anwendungsentwicklung; viele Empfehlungen zur Foliengestaltung lassen sich auf andere IT-Berufe übertragen. Sie beruhen auf meinen persönlichen Erfahrungen, wobei andere Prüfer:innen oder IHKs einzelne Punkte anders beurteilen können. Die 15 Minuten für deine Präsentation kannst du im Voraus üben. In den Prüfungen, die ich kenne, lässt dich der Prüfungsausschuss während dieser Zeit durchgehend vortragen. Bewertet werden die fachlichen Inhalte ebenso wie die Folien und dein Auftreten. Dazu gehört auch, wie du sprichst und mit Gestik oder Mimik arbeitest. Für die Präsentation gibt es eine gemeinsame Note. Mit Nervosität können Prüfer:innen umgehen. Fehlende fachliche Inhalte, etwa zur Wirtschaftlichkeit, führen zu Punktabzug. Einzelne kleine Schwächen beeinflussen die Note unterschiedlich stark; wenn mehrere zusammenkommen, kann sich das auf das Gesamtergebnis auswirken. Folien verständlich und lesbar gestalten Wenn du dein Projekt visuell zeigst, lässt sich dein Vorgehen anhand konkreter Beispiele nachvollziehen. Dafür eignen sich Diagramme aus deiner Projektarbeit oder Screenshots der Anwendung. Auch ein Foto einer problematischen Excel-Tabelle kann zeigen, warum dein Projekt nötig war. Blende Stichpunkte passend zum Vortrag ein. Sobald du einen Punkt besprichst, sollte dieser sichtbar werden. So bleibt die Aufmerksamkeit bei deinem aktuellen Thema. Prüfe die Schriftgröße aus Sicht des Publikums. Sämtliche Texte auf deinen Folien müssen auch vom Sitzplatz der Prüfer:innen aus lesbar sein. Halte Platz für die fachlichen Inhalte frei. Ich empfehle, Seitenzahlen und Datum wegzulassen. Eine mitlaufende Agenda beansprucht ebenfalls Fläche. Das Firmenlogo kannst du auf der Startfolie zeigen. Wähle Bilder aus deinem Projekt. Generische Cliparts vermitteln wenig über das konkrete Problem in deinem Betrieb. Prüfe die Rechtschreibung. Lass deine Folien gegenlesen und führe die Präsentation vor deinem/deiner Ausbilder:in oder weiteren IT-Azubis vor. Bei Diagrammen lohnt es sich, die Farben an deine übrigen Folien anzupassen. Verschiedene Farbtöne müssen dabei deutlich unterscheidbar bleiben. Unveränderte Standarddiagramme aus PowerPoint wirken schnell wie eingefügte Fremdkörper. Deine Präsentation persönlich gestalten Wenn mehrere IT-Azubis aus demselben Betrieb das gleiche Layout und einen identischen Aufbau übernehmen, wirken ihre Präsentationen austauschbar. Gestalte deine Folien passend zu deinem Projekt, damit deine eigene Arbeit erkennbar wird. Ich empfehle dir, mit dem Projektthema einzusteigen und dich anschließend kurz vorzu

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. TL;DR Aus meinen Erfahrungen mit der Sommerprüfung 2022 habe ich Hinweise für deine Projektdokumentation zusammengestellt: Dein Projekt muss fachlich verständlich sein, wobei du deine Entscheidungen und deine eigene Arbeit nachvollziehbar beschreibst. Bei der Kostenplanung gehören die betrieblichen Stundensätze ebenso dazu wie laufende Kosten und die Zeit weiterer Beteiligter. Zeige konkrete Ergebnisse deiner Qualitätssicherung und setze Technologien ein, mit denen du vertraut bist. Für deine Prüfung gelten die Vorgaben deiner IHK und deiner Prüfer:innen. Kapitelmarken [00:00:00] Einstieg und Rückblick auf die Sommerprüfung 2022 [00:02:30] Meine Erfahrungen und die Vorgaben deiner IHK [00:04:02] Fachliche Inhalte und formale Details bewerten [00:05:28] Messaging und Microservices passend einsetzen [00:08:34] Das Projekt mit Use-Case-Diagrammen verständlich machen [00:09:51] ER-Modell und Tabellenmodell richtig benennen [00:11:48] Technologien vor dem Abschlussprojekt kennenlernen [00:13:15] Anhänge im Fließtext erklären und referenzieren [00:16:34] Blocksatz und Gliederungstiefe [00:19:49] Kapitel mit Inhalt füllen und Word-Verweise prüfen [00:21:23] Stundensätze aus Sicht des Betriebs bestimmen [00:25:57] Stundensätze konsistent verwenden [00:27:58] Firmengeheimnisse und Datenschutz [00:29:44] Laufende Kosten berücksichtigen [00:31:52] Arbeitszeit und Kosten weiterer Beteiligter [00:34:48] Entscheidungen anhand der Anforderungen begründen [00:37:15] Eigene Leistung sprachlich erkennbar machen [00:38:21] Nutzwertanalysen nachvollziehbar bewerten [00:39:52] Vorgehensmodell und Anforderungen festhalten [00:40:58] Lastenheft und Pflichtenheft [00:43:48] Aussagekräftige Anforderungen und technische Angaben [00:46:26] Inhalte innerhalb der Seitengrenze auswählen [00:47:19] Zeitplanung und Qualitätssicherung [00:49:10] Projektspezifische Inhalte statt allgemeiner Erklärungen [00:51:16] Standardisierte Diagramme verwenden [00:52:32] Soll-Ist-Vergleich nachvollziehbar rechnen [00:55:05] SSH-Sicherheit und Schlüsselprüfung [00:57:29] Aufgaben in der Detailplanung aufteilen [00:59:05] Low-Code im Abschlussprojekt Anwendungsentwicklung [01:00:34] REST-APIs absichern [01:02:07] REST-Ressourcen und HTTP-Methoden [01:04:48] Code-Review-Ergebnisse konkret dokumentieren [01:07:34] Eigene Arbeit durch sichtbare Artefakte belegen [01:08:47] Weiterführende Beiträge und Ausblick [01:09:35] Newsletter passend zum Ausbildungsstand Inhalt Projektdokumentationen Sommer 2022 (Fachinformatiker:in Anwendungsentwicklung) Disclaimer: Meine Meinung ist nicht stellvertretend für alle Prüfungsausschüsse in Deutschland. Ich schaue oft auch auf die formellen Details, aber wichtiger sind natürlich immer die fachlichen/technischen Inhalte. Einzelne Punkte auf der folgenden Liste führen nicht zwangsläufig zu Punktabzug bei der Note, aber oft treten mehrere Punkte gemeinsam auf, was dann einen Punktabzug rechtfertigt. Viele "Probleme" mit den Projektdokumentationen gelten 1-zu-1 in allen IT-Berufen, da sie gar nichts mit Anwendungsentwicklung zu tun haben. Allgemeines Messaging wird in mehreren Projekten eingesetzt. Nur wenige Use-Case-Diagramme gesehen. -> Was macht das System eigentlich? Oft wurde ein Tabellenmodell ER-Modell genannt. Frameworks oder gar Programmiersprachen waren vor der Projektdurchführung nicht bekannt. Formalia Abbildungen wurden mit ihrem Namen referenziert, anstatt mit der Seitenzahl. Einige Dokumentationen waren im Flattersatz gesetzt. Eine Dokumentation hatte 5 (!) Ebenen im Inhaltsverzeichnis, also z.B. bis Kapitel 4.2.4.1.2. Ein Kapitel bestand nur aus einem (!) Aufzählungspunkt. "Textmarke nicht definiert" im Dokument. Stundensatzberechnung Es wurden verschiedene Stundensätze für einzelne Mitarbeiter angegeben, dann aber nur mit einem einheitlichen gerechnet. Der Stundensatz wurde oft nur aus der Azubivergütung berechnet (z.B. Vergütung / 20 / 8 -> 6 EUR/h). Ein Prüfling hat explizit geschrieben, dass der Stundensatz sich nur aus der Azubivergütung berechnet, setzt dann aber 75 EUR/h an. Oft wird der Datenschutz als Begründung genutzt, die echten Stundensätze nicht nennen zu können. Kosten Es wurden 500 EUR/Monat als laufende Kosten für einen (!) Server angesetzt. Die Abnahme wurde mit 3h eingeplant, aber nur mit 1h in den Kosten aufgeführt. Stunden des Fachbereichs tauchten nicht in den Kosten auf. Ein Prüfling hat die Stunden anderer Mitarbeiter mit in seine 70h aufsummiert. Begründung von Entscheidungen Begründung für technische Entscheidung: "Ich soll das so machen." Ein Prüfling hat durchgängig geschrieben, dass "man" das Projekt umgesetzt hat. Es gab eine Nutzwertanalyse, bei der die Eigenentwicklung in allen (!) Kriterien die maximale Punktzahl hatte. Anforderungsermittlung Im Lastenheft wurde vom Kunden angeblich Java 11 und Messaging gefordert. Ein Lastenheft bestand nur aus zwei Sätzen und das dazu passende Pflichtenheft war "nicht nötig". Die Programmiersprache wurde in einer gesamten Dokumentation nicht genannt. Fehlende oder überflüssige Inhalte Eine Dokumentation enthielt keinerlei Zeitplanung, Phasen oder Prozess. Die Qualitätssicherung fehlt oft komplett (z.B. Testen, CI/CD, Reviews). Auf 1/2 Seite wurde Scrum im Detail erklärt bzw. auf einer ganzen Seite REST. Sonstiges Ein Prüfling hat sich eigene Diagrammformen ausgedacht, anstatt einfach UML zu nutzen. Beim Soll-Ist-Vergleich wurde Soll - Ist gerechnet. Security wurde bei SSH absichtlich ausgeschaltet. In einer Detailplanung war ein Block 23h lang. Es wurde mit einer Low-Code-Plattform gearbeitet, für die es eigentlich nichts zu programmieren gab. REST wird inzwischen sehr oft verwendet, aber die wenigsten Prüflinge wissen, wie man die APIs absichert. REST-APIs sehen oft sehr seltsam aus ("GetById" im Path). Positiv aufgefallen Das Code-Review hat tatsächlich auch mögliche Optimierungen ergeben (Namen, Struktur). Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Datenbankmodellierung (Lernzielkontrolle zum relationalen Tabellenmodell) Datenbankmodellierung (Lernzielkontrolle zum Entity-Relationship-Modell) Welche Programmiersprache du für dein Abschlussprojekt verwenden solltest Berechnung des eigenen Stundensatzes in der Projektdokumentation (FAQ) Datenschutz vs. Datensicherheit vs. Datensicherung Nutzwertanalyse in der Projektdokumentation Lasten- und Pflichtenheft in der Projektdokumentation Scrum Einführung in Continuous Integration Unit-Tests - Häufige Fragen im Fachgespräch Elena Hollen über Code Reviews und Extreme Programming Zusammenfassung Woher meine Hinweise kommen Als Prüfer für Fachinformatiker:innen Anwendungsentwicklung bei der IHK Oldenburg habe ich Projektdokumentationen aus der Sommerprüfung 2022 gelesen. Viele der dabei aufgefallenen Punkte betreffen auch andere IT-Berufe. Meine Hinweise beruhen auf diesen Erfahrungen; für deine Prüfung sind die Vorgaben deiner IHK und deiner Prüfer:innen maßgeblich. Die geprüften Projekte wurden noch nach der alten Prüfungsordnung mit 70 Stunden durchgeführt. Für Anwendungsentwicklungsprojekte nach der neuen Ordnung stehen 80 Stunden zur Verfügung. Bei meiner IHK war der Fließtext auf 15 Seiten begrenzt, während die gesamte Dokumentation einschließlich Anhang häufig etwa 50 Seiten umfasste. Dein Projekt verständlich beschreiben Wer deine Dokumentation liest, muss verstehen können, welche fachliche Aufgabe dein System erfüllt. Ein Use-Case-Diagramm zeigt die beteiligten Akteur:innen und die Anwendungsfälle auf einer abstrakten Ebene. Damit schaffst du einen Einstieg in dein Projekt. Nenne die verwendete Programmiersprache ausdrücklich, sodass deine Prüfer:innen sie direkt erkennen können. Beschreibe außerdem, wie du vorgegangen bist und welche Projektphasen du geplant hast. Bei Datenmodellen kommt es auf die passenden Begriffe an: Ein Entity-Relationship-Modell beschreibt Daten abstrakt und unabhängig davon, wie du später eine Datenbank aufbaust. Ein Tabellenmodell zeigt die Tabellen einer relationalen Datenbank. Es lässt sich aus einem ER-Modell ableiten. Auch andere Datenbankformen kommen infrage, etwa Dokumentendatenbanken oder Key-Value-Stores. Wenn du ein Diagramm benennst, sollte der Name zur gezeigten Darstellungsform passen. Technologien kennen und passend auswählen Bevor du mit deinem Abschlussprojekt beginnst, solltest du die eingesetzten Technologien bereits kennen und praktisch ausprobiert haben. Das gilt besonders für die Programmiersprache und zentrale Frameworks. Plane dafür genügend Vorlauf ein. Bei mehreren Projekten fiel mir auf, dass Messaging eingesetzt wurde, ohne den zusätzlichen Aufwand ausreichend zu berücksichtigen. Eine Message Queue, beispielsweise mit RabbitMQ, kann Systeme entkoppeln und Nachrichten asynchron weitergeben. Zur Entscheidung gehört, dass du dich auch mit möglichen Ausfällen des Brokers und der angebundenen Dienste beschäftigst. Wenn du sehr kleine Dienste auf mehrere Microservices verteilst, entstehen zusätzliche Komponenten, deren Betrieb du berücksichtigen musst. Begründe deshalb anhand deiner Anforderungen, welchen Beitrag die Architektur zu deinem Projekt leistet. Das gilt ebenso für Single-Page-Apps und andere technische Ansätze. Bei Low-Code-Plattformen sehe ich für das Abschlussprojekt in der Anwendungsentwicklung ein Problem: Deine Prüfer:innen müssen beurteilen können, ob du programmieren kannst. Wähle ein Projekt, in dem diese Fähigkeit sichtbar wird. Entscheidungen nachvollziehbar begründen Aus deiner Dokumentation sollte hervorgehen, warum du eine Lösung gewählt hast und wie sie zu den Anforderungen passt. Bei betrieblichen Vorgaben gehören die verantwortliche Stelle und der Hintergrund dazu. Eine Formulierung wie "Ich soll das so machen" lässt diese

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. TL;DR Bei Teil 1 der gestreckten Abschlussprüfung im Frühjahr 2022 habe ich vor allem praxisnahe Aufgaben zu Hardware und Netzwerken vorgefunden, ergänzt durch Präsentationsfolien und Aufgaben zu Software. In meinem IHK-Bezirk fiel der Schnitt schwach aus, wobei bei der Netzwerkaufgabe besonders viele Punkte verloren gingen. Für deine Prüfung solltest du Grundlagen sicher beherrschen und praktisch ausprobieren, Fachabkürzungen verstehen sowie jede Teilfrage vollständig beantworten. Kontrolliere außerdem das gesamte Prüfungsheft, weil hinter dem Konzeptpapier weitere Aufgaben stehen können. Kapitelmarken [00:00:00] Review zu Teil 1 der Abschlussprüfung im Frühjahr 2022 [00:02:30] Prüfungsaufbau und Aufgabe 1: Präsentationsfolien und Angebote [00:04:21] Aufgabe 2: CPU, RAM und SSDs [00:06:15] Anschlüsse, Prozessoren und Einheiten [00:08:22] Aufgabe 3: WLAN und RADIUS [00:10:09] ISO-OSI-Modell und praktische Fehlersuche [00:12:11] MAC-Adresse, IPv6 und DHCP [00:13:48] Subnetting und Ursache des Netzwerkproblems [00:15:18] Aufgabe 4: Struktogramm und Software [00:16:04] Kosten und Upload-Dauer berechnen [00:16:53] Praxisbezug und ungewohnte Aufgabenformate [00:17:59] Auffällige Antworten: RADIUS und Netzwerkgrundlagen [00:21:10] Subnetting bei einer /24-Netzmaske [00:22:02] Tipps: Grundlagen lernen und praktisch ausprobieren [00:24:32] Prüfungsheft prüfen und Teilfragen vollständig beantworten [00:26:49] Abkürzungen und Einheiten lernen [00:28:05] Ergebnisse im IHK-Bezirk und Schwierigkeiten bei Aufgabe 3 [00:31:47] Kostenlose Ausbildungsbegleitung per E-Mail 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) Zusammenfassung Prüfungsaufbau und Schwerpunkte Für mein Review von Teil 1 der gestreckten Abschlussprüfung im Frühjahr 2022 habe ich besonders die Netzwerkaufgabe untersucht, die ich selbst als Prüfer korrigiert habe. Meine Angaben zu den Ergebnissen beziehen sich auf meinen IHK-Bezirk. Die Prüfung umfasste vier verpflichtende Aufgaben mit insgesamt 100 Punkten, die jeweils 25 Punkte einbrachten. Du musstest alle Aufgaben bearbeiten. Hardware und Netzwerke nahmen viel Raum ein. Fotos von Anschlüssen sowie echte Windows-Screenshots stellten einen engen Bezug zur Praxis her. Wer sich mit alten GA2-Aufgaben oder den Themen der vorherigen Prüfung vorbereitet hatte, traf auf ungewohnte Aufgabenformate. Projektmanagement und Netzpläne kamen diesmal nicht vor. Bei vielen Teilfragen genügten kurze Stichpunkte oder einzelne Angaben. Aufgabe 1: Präsentationsfolien und Angebote Aus einem vorgegebenen Text solltest du Inhalte für Präsentationsfolien ableiten und passende Notizen in ein dafür vorgesehenes Feld schreiben. Weitere Teilfragen verlangten, Begriffe wie Big Data oder Industrie 4.0 so aufzubereiten, dass du sie einem/einer Kund:in präsentieren kannst. Auch die DSGVO gehörte dazu. Zum Angebot solltest du angeben, welche Inhalte hineingehören, und begründen, warum diese wichtig sind. Als Beispiel wurde gefragt, weshalb eigene Standorte im Angebot stehen sollten. Aufgabe 2: Hardware Bilder und kurze Texte dienten als Grundlage für mehrere Teilfragen. Gefragt waren unter anderem: Wie baust du eine CPU ein, und wozu brauchst du Wärmeleitpaste? Wie setzt du RAM-Riegel ein, damit sie im Dual-Channel-Betrieb arbeiten? Welche Vor- und Nachteile haben SSDs mit SATA- beziehungsweise M.2-Anschluss? Welche abgebildeten Anschlüsse heißen DVI, HDMI oder DisplayPort? Was sind logische Prozessoren, und was ist ein Cache-Speicher? Wie rechnest du Gigahertz in Hertz um? Bei der USB-Frage fiel mir auf, dass die Aufgabe USB-C mit USB 3 verglich und damit einen Steckertyp mit einer Versionsangabe vermischte. Gemeint war offenbar ein Vergleich der Anschlüsse USB-C und USB-A. Die Fragen zu Dual-Channel-RAM und M.2 hätte ich selbst nicht sicher beantworten können. Windows-Screenshots zur CPU boten Gelegenheit, Angaben aus einem laufenden System zu erklären. Aufgabe 3: Netzwerke und Fehlersuche Für einen Laptop, der mit einem WLAN verbunden werden sollte, waren zunächst SSID und Passwort gefragt. Anschließend solltest du WPA-PSK und RADIUS erklären. Bei RADIUS erhält jede:r Benutzer:in eigene Zugangsdaten; der Server übernimmt die zentrale Authentifizierung und verwaltet die Benutzer:innen. Eine Tabelle zum ISO-OSI-Modell brachte sechs Punkte. Für vier Schichten waren Angaben zu Protokollen und Adressen sowie möglichen Fehlern einzutragen. Danach ging es darum, eine gestörte Netzwerkverbindung anhand von Screenshots schrittweise zu untersuchen: Schicht 1 prüfen: Du solltest passende Angaben aus einem Screenshot auswählen, etwa die Signalstärke oder übertragene Bits. Weil bereits Daten übertragen worden waren, ließ sich begründen, dass diese Schicht funktionierte. Adressen erklären: In einer Ausgabe von ipconfig solltest du MAC- und IPv6-Adresse erkennen und ihre Herkunft beschreiben. Die MAC-Adresse war vom Hersteller vergeben worden. Die gezeigte lokale IPv6-Adresse hatte der Rechner anhand seiner MAC-Adresse selbst erzeugt. IP-Adressen zuweisen: Als zuständigen Server solltest du DHCP nennen. Hier wurde häufig DNS eingetragen. Subnetz bestimmen: Zur vorgegebenen Konfiguration waren Netz- und Broadcast-Adresse zu ermitteln. Die Host-Adresse stand bereits im Screenshot. Bei der verwendeten Maske /24, also 255.255.255.0, endete die Netzadresse auf .0 und die Broadcast-Adresse auf .255. Den Fehler herleiten: Der Laptop hatte zunächst keine IP-Adresse vom DHCP-Server erhalten. Nachdem laut Aufgabentext ipconfig /renew ausgeführt worden war, funktionierte die Verbindung. Daraus ließ sich das ursprüngliche Problem ableiten. Bei meinen Korrekturen waren häufig nur Teile einer Frage beantwortet. Wer eine Adresse benannte, ließ beispielsweise ihre Herkunft weg. Auch die geforderte Begründung, weshalb Schicht 1 funktionierte, fehlte oft. Die abschließende Diagnose gelang vielen Prüflingen nicht, obwohl die vorherigen Teilaufgaben Hinweise lieferten. Aufgabe 4: Software und Rechnen Für ein Struktogramm war der gesamte Code bereits vorgegeben. Du solltest die Bestandteile in die richtige Reihenfolge bringen und eintragen. Aus einem englischen Text waren Informationen zu Workspace-Management-Software abzuleiten, etwa zur Paketverteilung und zum Installieren von Software. Außerdem wurden Cloud und On-Premises behandelt. Bei einer Kostenaufgabe solltest du berechnen, ab welcher Anzahl gekaufter Lizenzen es sich lohnt, Software selbst zu entwickeln. Eine weitere Rechnung betraf die Dauer eines Datei-Uploads. Dafür war die angegebene Upload-Geschwindigkeit maßgeblich. Was du für deine schriftliche Prüfung üben solltest Aus den korrigierten Antworten habe ich folgende Hinweise für dich abgeleitet: Wiederkehrende Grundlagen lernen: Beschäftige dich mit dem ISO-OSI-Modell und Netzwerkdiensten wie DHCP und DNS. Auch Struktogramme und Monitoranschlüsse gehören zu den typischen Inhalten. Wissen praktisch anwenden: Führe ipconfig selbst aus und versuche, die Ausgabe zu verstehen. Schau dir Hardware im Betrieb an und frage, ob du einen PC auseinanderbauen oder ein Mainboard untersuchen darfst. Beim Anschließen eines USB-C-Steckers erfährst du beispielsweise direkt, dass beide Orientierungen passen. Das ganze Prüfungsheft kontrollieren: In dieser Prüfung war Konzeptpapier mitten in Aufgabe 3 eingeheftet. Einige Prüflinge hörten dort auf und ließen ungefähr anderthalb Aufgaben unbearbeitet. Jede Teilfrage vollständig lesen: Wenn eine Aufgabe eine Herkunft oder Begründung verlangt, gehört diese in deine Antwort. Schau bei zusammenhängenden Aufgaben auch auf die vorherigen Angaben zurück. Abkürzungen verstehen: Lerne die ausgeschriebenen Begriffe und ihre Bedeutung. DHCP steht für "Dynamic Host Configuration Protocol". RADIUS bedeutet "Remote Authentication Dial-in User Service". Daraus lässt sich die jeweilige Aufgabe der Technik ableiten

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. TL;DR Für deine gestreckte Abschlussprüfung Teil 1 vertiefe ich die Themen aus dem Projektmanagement: Mit Lewins Modell und Kaizen begleitest du Veränderungen, während du mit Root Cause Analysis und Five Whys den Ursachen von Problemen nachgehst. Bevor du ein Projekt umsetzt, prüfst du dessen Machbarkeit und bewertest die Kosten anhand betriebswirtschaftlicher Kennzahlen. Für die Zusammenarbeit im Team gehören Tuckmans Phasen ebenso zum Lernstoff wie das Harvard-Konzept und eine Kommunikation, die zu deinem Gegenüber passt. In Retrospektiven leitest du aus bisherigen Erfahrungen konkrete Schritte ab, mit denen du die Zusammenarbeit verbesserst. Kapitelmarken [00:00:38] Projektmanagement für die Abschlussprüfung Teil 1 [00:01:58] Change Management und Lewins Modell [00:06:23] Kaizen und kontinuierlich besser werden [00:09:24] Probleme untersuchen und die Umsetzungshilfe "Ausbildung gestalten" [00:11:16] Root Cause Analysis [00:13:08] Five Whys [00:15:15] Arbeitsmittel und Ressourcen wirtschaftlich einsetzen [00:16:31] Die Machbarkeit eines Projekts prüfen [00:19:46] Make-or-Buy [00:21:50] Effektivität und Effizienz [00:24:01] Budget planen und einhalten [00:25:13] Betriebswirtschaftliche Kennzahlen für die Prüfung [00:26:01] Umsatz und Gewinn [00:27:40] Fixe und variable Kosten [00:29:13] Deckungsbeitrag [00:31:09] Rentabilität [00:33:15] Amortisation berechnen und bewerten [00:36:38] Aufgaben im Team und mit Kund:innen abstimmen [00:37:23] Tuckmans Phasen der Teamentwicklung [00:40:33] Win-Win-Strategie [00:44:10] Das Harvard-Konzept [00:47:00] BATNA als Alternative zur Verhandlung [00:49:57] Passend zum Gegenüber kommunizieren [00:52:27] Betriebswirtschaftliche Unternehmensdaten bewerten [00:53:24] Lessons Learned und Scrum-Retrospektive [00:56:26] Konstruktive Kritik geben [01:02:36] Abschluss des Themenbereichs und ergänzende Lernmaterialien Planen, Vorbereiten und Durchführen von Arbeitsaufgaben in Abstimmung mit den kundenspezifischen Geschäfts- und Leistungsprozessen Nachtrag zu Teil 1: Change Management (Prozess zur Umsetzung von Veränderungen in Unternehmen) z.B. nach Lewin (Unfreeze, Change, Refreeze) Kaizen, Continuous Improvement 1e: Probleme analysieren und als Aufgabe definieren sowie Lösungsalternativen entwickeln und beurteilen Analysieren im Sinne von Erkennen und Einordnen Problemlösungsvarianten entwickeln Probleme beseitigen durch, z.B.: Situationsanalyse Problemeingrenzung Aufzeigen von Alternativen Auswahl von Lösungen Analysieren der Chancen und Risiken der ausgewählten Lösung anhand vorher definierter Beurteilungskriterien Root-Cause-Analysis 5 Whys 1f: Arbeits- und Organisationsmittel wirtschaftlich und ökologisch unter Berücksichtigung der vorhandenen Ressourcen und der Budgetvorgaben einsetzen Berücksichtigung der Formen von Arbeitsorganisation, z.B.: Gruppenarbeit Pair Programming Budgetplanung als Teil der Unternehmensplanung effektiver und effizienter Einsatz von Arbeits- und Organisationsmitteln Prüfung des Ressourceneinsatzes auf: rechtliche Zulässigkeit technische und organisatorische Machbarkeit ökologische Nachhaltigkeit und Wirtschaftlichkeit Prüfung der Wirtschaftlichkeit mittels betriebswirtschaftlicher Methoden, z.B.: Rentabilitätsrechnung Amortisationsrechnung Machbarkeitsanalyse: technisch, organisatorisch, wirtschaftlich, zeitlich, rechtlich Make-or-buy-Entscheidung Effektivität: Die richtigen Dinge tun. Effizienz: Die Dinge richtig tun. Budget: die für einen bestimmten Zweck zur Verfügung stehenden Geldmittel Umsatz: Absatzmenge * Verkaufspreis Gewinn: Erlöse - Kosten Deckungsbeitrag: Stückpreis - variable Stückkosten Rentabilität: Gewinn / Kapital Amortisation: Investition / Ertrag pro Jahr 1g: Aufgaben im Team sowie mit internen und externen Kunden und Kundinnen planen und abstimmen Team als soziales Gefüge verstehen ("social awareness") Phasen der Teamentwicklung kennen und anwenden (Konflikt, Kontrakt, Kooperation) Methoden des sachbezogenen Verhandelns kennen und anwenden, z.B.: Win-win-Strategie Harvard-Konzept adressatengerechte Kommunikation Prozess der Teambildung nach Bruce Tuckman: Forming, Storming, Norming, Performing, (Adjourning) Win-win: Konfliktlösung ohne Verlierer Harvard-Konzept Menschen und Interessen trennen Fokus auf Interessen und nicht auf Positionen Entscheidungsoptionen entwickeln objektive Beurteilungskriterien anwenden BATNA: Best Alternative To a Negotiated Agreement Communication is what the listener does (Peter Drucker) 1h: betriebswirtschaftlich relevante Daten erheben und bewerten und dabei Geschäfts- und Leistungsprozesse berücksichtigen Bewerten anhand vorgegebener unternehmensspezifischer Daten 1i: eigene Vorgehensweise sowie die Aufgabendurchführung im Team reflektieren und bei der Verbesserung der Arbeitsprozesse mitwirken gemeinsame kritische Analyse der bisherigen Zusammenarbeit und der Ergebnisse ("lessons learnt") offenes Ansprechen von Erfolgen und Problemen gemeinsame Entwicklung von Maßnahmen zur Verbesserung, z.B. SCRUM-Retrospektive konstruktive Kritik Retrospektive: Wie kann der Prozess und die Zusammenarbeit im Team verbessert werden? konstruktive Kritik: konkrete Wahrnehmung schildern (nicht interpretieren, nicht verallgemeinern), Auswirkungen aufzeigen, Ich-Botschaft senden, Wunsch äußern Literaturempfehlungen Das hier ist die "Handreichung", von der ich im Podcast spreche: * * * * * Links Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts 7 Change Management Methoden, die du kennen solltest Mein Projekt amortisiert sich nicht Anforderungsermittlung (nicht nur für dein Abschlussprojekt) Manager Tools Zusammenfassung Projektmanagement für die Abschlussprüfung Teil 1 Für deine schriftliche IHK-Prüfung greife ich die noch offenen Punkte aus dem Themenbereich Projektmanagement auf. Dazu gehören die Unterpunkte 1e bis 1i des Ausbildungsrahmenplans sowie ergänzend das Change Management. Die vorherigen Punkte habe ich in Episode 172 behandelt. Als Grundlage verwende ich die Umsetzungshilfe "Ausbildung gestalten" des Bundesinstituts für Berufsbildung. Sie konkretisiert den Ausbildungsrahmenplan und ist als Buch sowie als PDF erhältlich. An ihr haben Personen mitgearbeitet, die auch an der Neuordnung der IT-Berufe beteiligt waren. Veränderungen im Unternehmen begleiten Lewins Modell Wenn ein Unternehmen seine Abläufe verändert, können Beschäftigte an vertrauten Verfahren festhalten. Ihre Erfahrungen und Gründe verdienen Beachtung. Im Change Management geht es deshalb auch darum, die Beteiligten von einer Veränderung zu überzeugen und sie währenddessen zu begleiten. Lewins Modell beschreibt folgende Phasen: Unfreeze: Du bereitest die Veränderung vor und lockerst eingefahrene Strukturen. Die Beteiligten sollen verstehen, welchen Vorteil der neue Ablauf bringt, etwa weniger Kosten oder schnelleres Arbeiten. Change: Während der neue Ablauf eingeführt wird, müssen sich die Beteiligten daran gewöhnen. Dabei sinkt zunächst häufig die Produktivität. In dieser Phase brauchen sie weiterhin Unterstützung. Refreeze: Sobald der neue Prozess funktioniert, wird er zum festen Bestandteil des Arbeitsalltags. Angestrebt wird ein höheres Leistungsniveau, das durch verlässliche Abläufe erhalten bleibt. Weitere Modelle umfassen fünf oder acht Phasen. Change Management steht ausdrücklich im Ausbildungsrahmenplan. Kaizen und kontinuierlich besser werden In der IT folgen Veränderungen oft schnell aufeinander. Kaizen, auch Continuous Improvement oder kontinuierlicher Verbesserungsprozess genannt, beschreibt das fortlaufende Verbessern der Arbeit. Als Beispiel greife ich Toyota auf: Dort darf jede:r Mitarbeiter:in das Produktionsband anhalten, wenn ein Fehler auffällt. Dadurch lässt sich die Ursache beheben, bevor weitere Fahrzeuge mit demselben Fehler entstehen. Auch wenn der Stillstand Geld kostet, trägt dieses Vorgehen dazu bei, die Qualität dauerhaft zu verbessern. Probleme untersuchen und Lösungen entwickeln Beim Unterpunkt 1e erkennst du ein Problem und grenzt es ein. Anschließend entwickelst du mögliche Lösungen, deren Chancen und Risiken du anhand vorher festgelegter Kriterien bewertest. Root Cause Analysis Mit der Root Cause Analysis suchst du die Ursache eines Fehlers und behebst ihn dort, wo er entsteht. Bei Software kann ein Fehler an einer anderen Stelle sichtbar werden: Eine falsche Zahl in der Oberfläche kann beispielsweise aus einer fehlerhaften Berechnung in der Geschäftslogik stammen. Dann setzt du bei dieser Berechnung an. Five Whys Bei den Five Whys fragst du wiederholt nach dem Warum. Jede Antwort bildet den Ausgangspunkt für die nächste Frage, wodurch du dich der zugrunde liegenden Ursache näherst. Die Zahl fünf dient dabei als Orientierung. Entscheidend ist, dass du weiter nachfragst und aus der erkannten Ursache passende Lösungen ableitest. Arbeitsmittel und Ressourcen sinnvoll einsetzen Unterpunkt 1f umfasst das Arbeiten innerhalb des verfügbaren Budgets und berücksichtigt ökologische Fragen. Die Umsetzungshilfe nennt außerdem Gruppenarbeit und Pair Programming. Beim Einsatz von Ressourcen prüfst du unter anderem, ob das Vorgehen rechtlich zulässig ist und sich technisch sowie organisatorisch umsetzen lässt. Die Machbarkeit eines Projekts prüfen Bevor du mit einem Projekt beginnst, untersuchst du mehrere Aspekte: Technik: Lässt sich die gewünschte Lösung mit den verfügbaren technischen Möglichkeiten umsetzen? Organisation: Gibt es ausreichend qualifizierte Mitarbeiter:innen und freie Kapazitäten? Trägt das Unternehmen das Vorhaben mit? Wirtschaftlichkeit: Sind die Kosten für das Unternehmen tragbar und angemessen? Zeit: Kann das Projekt innerhalb der vorgegebenen Frist fertig werden? Recht: Ist das Vorhaben erlaubt?...