In dieser Sonder-Episode des IT-Berufe-Podcasts geht es um eine Stellenausschreibung als Mitarbeiter (m/w/d) für den IT-Bereich Operative Informationssicherheit 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 Mitarbeiter (m/w/d) für den IT-Bereich Operative Informationssicherheit aus.

Kurzübersicht der Stelle

• Bezeichnung: Mitarbeiter (m/w/d) für den IT-Bereich Operative Informationssicherheit
• 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 11 und SUSE Linux
  • Virtualisierung mit Citrix und VMware
• 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.

Mitarbeiter (m/w/d) für den IT-Bereich Operative Informationssicherheit

Mitarbeiter (m/w/d) für den IT-Bereich Operative Informationssicherheit

Wir suchen zum nächstmöglichen Zeitpunkt einen Mitarbeiter (m/w/d) für den IT-Bereich Operative Informationssicherheit in Festanstellung.

Deine Aufgaben

• Erstellung von Dokumenten im Rahmen des Information Security Management Systems (ISMS)
• Risikoanalysen und Durchführung der dazugehörigen Maßnahmen
• Aufbau und Betreuung eines zentralen Dienstleistermanagements in der IT
• Kontrollen im Rahmen eines Security Operations Centers (SOC)
• IT-Assetmanagement: Pflege und Aktualisierung der IT-Assets in Zusammenarbeit mit den Prozess-, Produkt- und Serververantwortlichen
• IT-Notfallmanagement mit Notfallübungen und der kontinuierlichen Pflege der Dokumentation

Deine neue Abteilung

Die Abteilung IT-Betrieb & Anforderungen übernimmt unterschiedliche Aufgaben hinsichtlich IT-Infrastruktur, Support, technischer Redaktion und Anforderungsmanagement. Zur Abteilung gehören derzeit neun Mitarbeiterinnen und Mitarbeiter. Die im Folgenden genannten Aufgabenbereiche beziehen sich oftmals nicht nur auf die Abteilung. Daher gehört die Zusammenarbeit mit den anderen IT-Abteilungen, den Fachabteilungen sowie Stabsbereichen, aber auch zu anderen Unternehmen aus dem Konzern zum Alltag.

Der Betrieb und die Erweiterung der bestehenden Server- und Client-Infrastruktur für über 300 Anwenderinnen und Anwender umfasst sowohl Windows- als auch Linux-Systeme. Hier werden im Bedarfsfall auch Scripting bzw. Automatisierungen für Routineaufgaben genutzt. Sollte mal etwas nicht wie gewünscht laufen, dann gehören auch Störungsanalysen und -behebungen zu den Aufgaben. Um die Zukunft der Infrastruktur zu sichern, wird auch Wert auf Themen wie Sicherheit, Performance, Wartbarkeit und Skalierbarkeit gelegt. Im Support sind wir für alle Mitarbeiterinnen und Mitarbeiter da und unterstützen bei kleinen und großen Problemen.

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
• Mitarbeiter (m/w/d) für den IT-Bereich Operative Informationssicherheit bei der ALTE OLDENBURGER Krankenversicherung AG in Vechta

Der Beitrag Stellenangebot: Mitarbeiter (m/w/d) für den IT-Bereich Operative Informationssicherheit in Vechta – IT-Berufe-Podcast erschien zuerst auf IT-Berufe-Podcast.

Um die Änderungen im Prüfungskatalog für die AP2 als Fachinformatiker Anwendungsentwicklung ab 2025 geht es in der einhunderteinundneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Zur AP2 (Gestreckte Abschlussprüfung Teil 2) als Fachinformatiker Anwendungsentwicklung im Sommer 2025 gilt ein neuer Prüfungskatalog. Ich habe die Unterschiede zusammengestellt.

Zusammenfassung

Die folgenden Punkte fassen die zentralen Änderungen (aus meiner Sicht) zusammen.

Zusätzliche bzw. genauer spezifizierte Inhalte

• Anomalien/Redundanzen in Datenbanken erkennen
• SQL (detailliertes Beiblatt)
• Last-/Performancetests
• potentielle Angriffe wie Man-in-the-Middle, SQL-Injection, DDoS-Attacke
• Kerberos
• ODBC
• Monitoring von Systemen
• Programm- und Konfigurationsdokumentation
• NAS und SAN
• Softwarequalitätsmerkmale
• Cyber-physische Systeme
• Test Driven Development (TDD)
• Scrum
• Architektur-Pattern
• Kapselung in der Objektorientierung
• Sortierverfahren wie Bubble/Selection/Insertion Sort

Gestrichene Inhalte

• „Trends“ wie Smart Grid, IoT, Industrie 4.0, KI, Blockchain, Big Data, Augmented Reality
• Struktogramm (Nassi-Shneiderman) und Programmablaufplan (PAP)
• Load Balancing
• Data Warehouse
• Programmierparadigmen

Detaillierter Vergleich der bisherigen und neuen Inhalte des Prüfungskatalogs für die AP2 als Fachinformatiker Anwendungsentwicklung

In der folgenden Tabelle habe ich alle Unterschiede zwischen altem (ab 2020) und neuem (ab 2025) Prüfungskatalog für die AP2 als Fachinformatiker Anwendungsentwicklung gegenübergestellt.

• Rote Punkte habe ich im neuen Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen so nicht mehr erwartet.
• Grüne Punkte habe ich im alten Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen zusätzlich erwartet.
• Wenn sich lediglich Formulierungen oder Aufteilungen geändert haben, aber die Punkte inhaltlich gleich geblieben sind, stehen sie gar nicht in der Tabelle.
• Wenn Punkte an andere Stellen im Prüfungskatalog verschoben wurden, habe ich das in den Spalten Alter Unterpunkt und Neuer Unterpunkt gekennzeichnet.
• Meine persönliche (!) Bewertung (hin und wieder leicht ironisch) der Änderungen stehen in der Spalte Kommentar.
• Ein „x“ in Spalte wichtig deutet auf eine zentrale Änderung hin, die sich meiner Meinung nach merklich auf die Prüfungsvorbereitung der Azubis auswirkt.
• Die Punkte haben Präfixe, weil sie sich sonst doppeln. FÜ steht für Fachrichtungsübergreifende berufsprofilgebende Fertigkeiten, Kenntnisse und Fähigkeiten und BP für Berufsprofilgebende Fertigkeiten, Kenntnisse und Fähigkeiten in der Fachrichtung Anwendungsentwicklung.

Unterpunkt Alter Inhalt Neuer Inhalt Alter Unterpunkt Neuer Unterpunkt Kommentar wichtig FÜ-01.02 BGB/HGB Chancen und Risiken der technischen Entwicklungen kennen und identifizieren können FÜ-02.01 die „Trends“ von gestern sind der Normalzustand heute Ausfallsicherheit, bspw. redundante Systeme, selbstkonfigurierende Systeme FÜ-02.01 Lebenslanges Lernen FÜ-02.01 wie soll man das auch abfragen!? Teilhabe, soziale Stabilität FÜ-02.01 wird hoffentlich in WiSo abgedeckt Veränderungen von Einsatzfeldern kennen und beurteilen können FÜ-02.02 Geräteklassen FÜ-02.02 schon in AP1 Vernetzung, Integration und Modularisierung, Zentralisierung/Dezentralisierung, Embedded Systems FÜ-02.02 Smart Grid FÜ-02.02 IoT, Industrie 4.0 FÜ-02.02 eher was für den FIDV Kl, autonome Systeme FÜ-02.02 das ist ja jetzt auch schon in AP1 drin Big Data FÜ-02.02 das fände ich schon noch wichtig für FIAE Cloud On Premises, Cloud … FÜ-02.02 BP-02.04 Block Chain, Smart Contracts FÜ-02.02 das war wirklich nur ein Hype Augmented Reality FÜ-02.02 eher was für den neuen Beruf „Gestalter/-in für immersive Medien“ FÜ-02.01 Komponententest, Funktionstest, Integrationstest Komponententest, Integrationstest, Systemtest FÜ-03.01 FÜ-02.01 FÜ-02.02 Abbildung der Kontrollstrukturen mittels Struktogramm, PAP oder Pseudocode als didaktisches Hilfsmittel Abbildung der Kontrollstrukturen mittels Aktivitätsdiagramm oder Pseudocode als didaktisches Hilfsmittel FÜ-03.02 FÜ-02.02 goodbye Struktogramm und PAP x FÜ-02.03 Anomalien/Redundanzen erkennen kann gefühlt in jedem Fachgespräch dran x FÜ-02.03 Tabellenstruktur (CREATE TABLE, ALTER TABLE), Index (CREATE INDEX), Manipulation (INSERT, UPDATE, DELETE), Projektion (SELECT FROM) Selektion (SELECT FROM …WHERE) und (SELECT … (SELECT …)), Sortieren (ORDER BY), Gruppieren (GROUP BY, HAVING) SQL (siehe Anhang des Prüfungskatalogs): Tabellenstruktur Index Manipulation, Projektion, Selektion, Sortieren, Gruppieren FÜ-03.03 also gut die Inhalte des Beiblatts lernen x FÜ-03.01 Software-Test, dynamische und statische Testverfahren (z. B. Black Box, White Box, Review, Extremwertetest, Testdaten) Software-Test, dynamische und statische Testverfahren (z. B. Black Box, White Box, Review, Extremwertetest, Testdaten, Last- und Performancetest) FÜ-04.01 FÜ-03.01 Netzwerkanalyse, Bandbreite, Reaktionszeiten FÜ-04.01 FÜ-03.02 Hardwaretest, z. B. Wareneingangskontrolle, mangelhafte Lieferung, Warenausgangskontrolle, Abnahmeprotokoll Abnahmeprotokoll FÜ-04.02 FÜ-04.04 Technisch Organisatorische Maßnahmen (TOM) FÜ-04.04 Bedrohungsszenarien, z. B. Man-in-the-Middle, SQL-Injection, DDoS-Attack die wichtigsten Angriffe sollte jede:r FIAE kennen x BP-01.02 Switch; Bridge; Router BP-01.03 Verschlüsselung (preshared key, RADIUS …) Zugriffskontrolle im Netzwerk (RADIUS, Kerberos …) x BP-01.03. Drahtlos: PAN/WLAN Drahtlos: PAN/WLAN/Mesh BP-01.03 Netzwerkplan Netzwerkplan BP-01.04 BP-01.03 Netzwerktopologie (FI DV/SI) Netzwerktopologie (FI DV/FI SI) BP-01.04 BP-01.04 Dateifreigaben, z. B, SMB/CIFS BP-01.04 Datenabruf, z. B. HTTP, ODBC x BP-01.07 Netzwerkrelevante Dienste administrieren können Netzwerkrelevante Dienste beschreiben können das ist für FIAE auch ausreichend BP-01.08 Anwendungsdienste sicherstellen können Anforderungen an Verfügbarkeit von Anwendungsdiensten beurteilen können BP-01.11 Festlegen der Monitoringdaten BP-01.11 Festlegen von Schwellwerten BP-01.11 Load Balancing BP-01.12 Incident Management (Ticketsystem) Incident Management (Ticketsystem) BP-01.11 BP-01.12 Eskalationsstufen BP-01.13 Programm- und Konfigurationsdokumentation wurde vorher tatsächlich nicht genannt x BP-01.13 Checklisten BP-02.02 Elementarrisiken, z. B. Feuer, Hochwasser BP-02.03 Verschlüsselung (TPM) Verschlüsselung, z. B. Bitlocker BP-02.04 Fog, Cloud On Premises, Cloud BP-02.04 SaaS, XaaS SaaS, laaS, PaaS Xaas enthielt ja eigentlich schon alle Varianten BP-02.05 Data Warehouse BP-02.05 Datenaustauschformate: XML, JSON, CSV u. a. die Formate stehen aber noch an zwei anderen Stellen BP-02.06 NAS; SAN BP-03.01 Anforderungen kundengerecht erfassen können Softwareanforderungen erfassen können BP-03.01 Änderbarkeit Änderbarkeit/Erweiterbarkeit an Liste der ISO25001 angepasst x BP-03.01 Wartbarkeit x BP-03.02 Relationales Datenbankmodell steht schon mehrfach im Katalog BP-03.03 Datenbankverbindung implementieren BP-03.03 API API, z.B. REST steht schon mehrfach im Katalog BP-03.04 Programmierparadigma (Skriptsprache, Compilersprache …) das erstaunt mich ein wenig BP-03.04 Aufwand BP-03.06 Cyber-physische Systeme beschreiben und erweitern können ich dachte dafür haben wir den FIDV x BP-03.06 CPS-Software; Auswahl von geeigneten Sensoren/Aktoren; Nutzung von Bibliotheken; Abfragerhythmus planen; Kenntnis des Zugriffs auf Sensoren und Aktoren x BP-03.08 Qualitätssicherung und Tests; Black Box-/White Box-Tests steht schon mehrfach im Katalog BP-03.08 Grundsätzliches Vorgehen beim Testen, z. B. print-Debugging, TDD, Unit-Test, E2E Test hurra, TDD! x BP-04.01 Lasten-/Pflichtenheft erstellen können BP-04.08 BP-04.02 Scrum stand vorher tatsächlich nicht explizit im Katalog x BP-04.07 Software-Entwicklungswerkzeuge aufgabenbezogen anwenden können Software-Entwicklungswerkzeuge aufgabenbezogen auswählen und anwenden können BP-04.06 BP-04.12 Design-Pattern anwenden können Architektur- und Design-Pattern anwenden können, z. B. ui, Architektur kommt dazu und Liste der Pattern ist nur beispielhaft x BP-04.16 Struktogramm; PAP endlich! x BP-04.17 Objektorientierte Programmiermethoden anwenden können, z. B. Objektorientierte Programmiermethodenkonzepte anwenden können, z. B. was für ein Wort! x BP-04.17 Kapselung wer das nicht gelernt hat, war selbst schuld x BP-04.18 Bubble Sort Elementares Sortieren, z, B. Bubble Sort, Selection Sort, Insertion Sort x BP-04.22 Datenbankabfrage, Datenpflege mit SQL erstellen können Datenbankabfrage, Datenpflege mit SQL erstellen können -> Verweis auf Belegsatz alles lernen, was im Belegsatz steht x BP-05.03 Modultests erstellen und durchführen können (Unit-Tests) BP-05.03 die einzelnen Punkte wurden zusammengefasst BP-05.03 Softwaretests erstellen, durchführen und die Ergebnisse analysieren können Softwaretests erstellen, durchführen und die Ergebnisse analysieren können BP-05.05

Literaturempfehlungen

Das hier ist der „offizielle“ Prüfungskatalog für den Fachinformatiker Anwendungsentwicklung:

• Fachinformatiker / Fachinformatikerin – Anwendungsentwicklung Prüfungskatalog für die IHK-Abschlussprüfung

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Ich habe meine Themenliste zur AP2 als FIAE natürlich passend zu den Änderungen aktualisiert: Mögliche Themen von Teil 2 der gestreckten Abschlussprüfung (GAP) für Fachinformatiker Anwendungsentwicklung

Der Beitrag Neuer Prüfungskatalog für die AP2 als Fachinformatiker Anwendungsentwicklung ab 2025 – IT-Berufe-Podcast #191 erschien zuerst auf IT-Berufe-Podcast.

Kostenfreie Prüfungsvorbereitungskurse zur AP1 und AP2 FIAE

Kurz vor der letzten AP2 im November 2025 habe ich bereits einmal zwei Termine zur gemeinsamen Prüfungsvorbereitung angeboten.

Leider kam mir dann eine Erkrankung dazwischen und ich konnte keinen von beiden Terminen anbieten.

Als ich so darüber nachdachte, kam mir die Idee, einen längerfristigen Prüfungsvorbereitungskurs anzubieten. Denn ganz ehrlich: Was bringen zwei Termine kurz vor der Prüfung?

Ich selbst predige ja seit Jahren im Podcast, dass man früh genug anfangen soll, für die Prüfung zu lernen. Also ist es doch eigentlich nur konsequent, auch langfristig Termine für die Prüfungsvorbereitung anzubieten und nicht erst in der Woche vor der Prüfung. Und das mache ich jetzt einfach!

In einigen Wochen bzw. Monaten stehen die nächste AP1 und AP2 in den IT-Berufen an.

• AP1: 25.03.2025
• AP2: 07.05.2025

Deswegen biete ich für beide Prüfungen bis dahin wöchentlich einen Vorbereitungstermin an. Die AP1 ist natürlich für alle IT-Berufe identisch, aber bei AP2 konzentriere ich mich auf den Beruf Fachinformatiker Anwendungsentwicklung (FIAE).

Wenn du Interesse an einem der Termine hast, kannst du dich gerne unverbindlich für meinen Newsletter anmelden. Ich werde dir dann rechtzeitig zum nächsten Termin die nötigen Zugangsdaten für unseren Termin schicken.

Anmeldung zum IT-Berufe-Newsletter

Hier geht es direkt zur Anmeldung: IT-Berufe-Newsletter

Informationen zu den Prüfungsvorbereitungskursen

Hier kommen die wichtigsten Eckdaten zu den beiden Kursen:

• Plattform: Microsoft Teams
• Zeitpunkt
  • AP1: Dienstag von 18 bis 19 Uhr
  • AP2: Donnerstag von 18 bis 19 Uhr
• Preis: Kostenlos, aber ich würde mich über eine kleine Spende freuen, wenn du möchtest.
• Themen: Grundsätzlich alles, was in den jeweiligen Prüfungen drankommen kann. Ich würde immer ein paar Themen vorbereiten, mich aber danach richten, was die Teilnehmenden sich wünschen. Falls du Themenwünsche hast, antworte mir gerne einfach auf die E-Mails des Newsletters.
• Format: Interaktive Online-Nachhilfe zur Prüfungsvorbereitung. Ich würde Kameras und Mikros der Teilnehmenden erstmal ausschalten, aber über den Chat kann sich jede:r mit Fragen und Anmerkungen beteiligen. Wenn es gut läuft, können wir Mikro und Kamera aber später auch wieder anschalten.
• Aufzeichnung: Die Termine werden aufgezeichnet, aber nur für mich persönlich. Ich stelle sie nicht im Nachgang zur Verfügung, weder individuell noch öffentlich. Es handelt sich also ausschließlich um Live-Veranstaltungen.
• An-/Abmeldung: Der Kurs ist unverbindlich und du musst dich nicht für jeden Termin an- und abmelden. Ich verschicke rechtzeitig vor jedem Termin die Zugangsdaten und eine Erinnerung. Wenn du keine Lust mehr auf den Kurs hast, kannst du dich mit einem Klick auf einen Link in jeder dieser E-Mails davon abmelden.
• Dauer: Ich plane wöchentliche Termine bis zu den obigen Prüfungsterminen. Da aber alles unverbindlich und kostenfrei ist, kann es sein, dass einzelne Termine ausfallen, oder der Kurs ganz abgesagt wird, wenn sich zu wenig Teilnehmende anmelden. Ersatztermine wird es nicht geben.
• Teilnehmerkreis: Das Angebot ist exklusiv für meine Newsletter-Abonnent:innen. Der Link zu den Veranstaltungen wird wöchentlich geändert.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• IT-Berufe-Newsletter

Der Beitrag Kostenfreie Prüfungsvorbereitung für AP1 und AP2 FIAE – IT-Berufe-Podcast #999 erschien zuerst auf IT-Berufe-Podcast.

Um die Änderungen im Prüfungskatalog für die AP1 der IT-Berufe ab 2025 geht es in der einhundertneunzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Zur AP1 (Gestreckte Abschlussprüfung Teil 1) der IT-Berufe im Frühjahr 2025 gilt ein neuer Prüfungskatalog. Ich habe die Unterschiede zusammengestellt.

Zusammenfassung

Die folgenden Punkte fassen die zentralen Änderungen (aus meiner Sicht) zusammen.

Zusätzliche bzw. genauer spezifizierte Inhalte

• Projekte
  • Projektmerkmale
  • SMART-Prinzip
  • Wirtschaftlichkeit
  • Wasserfallmodell und Scrum
• Künstliche Intelligenz (KI)
• Software
  • Softwareprodukte wie ERP, SCM, CRM
  • Social Media
  • Barrierefreiheit auf Websites
• Netzwerkadministration
  • Einbindung eines PCs in eine Domäne
  • IPv4 und IPv6
• HDD vs. SSD
• Übertragungsraten, -zeiten und Datenmengen berechnen
• UML-Aktivitätsdiagramm
• Fehler in Code finden und Schreibtischtest durchführen
• IT-Sicherheit
  • Schutzziele (Vertraulichkeit, Verfügbarkeit, Integrität)
  • Hashverfahren
  • Zweifaktorauthentifizierung (2FA)
  • Härtung von Betriebssystemen
• Datenschutz
  • Betroffenenrechte nach DSGVO
  • Anonymisierung und Pseudonymisierung

Gestrichene Inhalte

• Projekte
  • Weitere Vorgehensmodelle außer Wasserfall und Scrum
  • SWOT-Analyse (Stärken/Schwächen)
• Hardware
  • SAN
  • RAID
• LTE und 5G
• Programmierung
  • Vererbung in der Objektorientierung
  • Struktogramm (Nassi-Shneiderman) und Programmablaufplan
  • Softwarequalitätskriterien
• Datenbanken
  • Alle nicht-relationalen Datenbanken
  • SQL
• ISO-Normen wie die 2700x
• Dokumentationen

Detaillierter Vergleich der bisherigen und neuen Inhalte des Prüfungskatalogs für die AP1 der IT-Berufe

In der folgenden Tabelle habe ich alle Unterschiede zwischen altem (ab 2020) und neuem (ab 2025) Prüfungskatalog für die AP1 der IT-Berufe gegenübergestellt.

• Rote Punkte habe ich im neuen Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen nicht mehr erwartet.
• Grüne Punkte habe ich im alten Prüfungskatalog nicht wiedergefunden. Sie werden daher in den neuen Prüfungen zusätzlich erwartet.
• Wenn sich lediglich Formulierungen oder Aufteilungen geändert haben, aber die Punkte inhaltlich gleich geblieben sind, stehen sie gar nicht in der Tabelle.
• Wenn Punkte an andere Stellen im Prüfungskatalog verschoben wurden, habe ich das in den Spalten Alter Unterpunkt und Neuer Unterpunkt gekennzeichnet.
• Meine persönliche (!) Bewertung (hin und wieder leicht ironisch) der Änderungen stehen in der Spalte Kommentar.
• Ein „x“ in Spalte wichtig deutet auf eine zentrale Änderung hin, die sich meiner Meinung nach merklich auf die Prüfungsvorbereitung der Azubis auswirkt.

Unterpunkt Alter Inhalt Neuer Inhalt Alter Unterpunkt Neuer Unterpunkt Kommentar wichtig 01.01 Merkmale eines Projektes war vorher tatsächlich nicht explizit genannt 01.01 SMART-Prinzip 01.01 Projektphasen Projektphasen am Beispiel des Wasserfallmodells bzw. SCRUM definieren können 01.01 Vorgehensmodelle XP, Kanban etc. werden dann wohl nicht mehr benötigt x 01.01 Teambildung und -entwicklung Phasen der Teambildung und -entwicklung kennen 01.02 Machbarkeit von Projekten beurteilen können Machbarkeit und Wirtschaftlichkeit von Projekten beurteilen können sinnvoll auch für das Abschlussprojekt 01.02 Vor- und Nachkalkulation 01.02 Stammdaten und Bewegungsdaten naja, wer arbeitet schon mit Daten!? 01.02 Betriebswirtschaftliche Kennzahlen, z. B. Umsatz, Gewinn, Deckungsbeitrag 07.02 Deckungsbeitrag war wohl zu schwierig 01.03 KI-Unterstützung muss heutzutage halt sein x 01.03 Supportanfragen Support- und Serviceanfragen (First-, Second- und Thirdlevelsupport) sinnvoll, die einzelnen Typen zu nennen 02.01 Angebotsbewertung Quantitative und qualitative Angebotsbewertung 02.02 Benchmarking hat eh niemand verwendet 02.02 Fragetechnik, aktives Zuhören, bedarfs- und adressatengerechte Präsentation ist auch schwer schriftlich abzufragen 02.03 Medien zur Kundenpräsentation und -Information, z. B. Kundengespräch via Webinaren Situationsgerechte Kundenkommunikation 02.03 Eisbergmodell 02.03 Cross-Selling; Upselling ist ja auch sehr Sales-lastig 02.03 Kundenbedarf ermitteln und Angebote unterbreiten 02.03 Interpretation englischsprachiger Texte 02.04 Technische und nicht-technische Texte; Auswertung von englischen Texten Technische und kaufmännische Texte in deutscher und englischer Sprache 02.04 Digitale Suchabfragen unter Verwendung von Suchoperatoren finde ich trotz KI weiterhin wichtig 02.04 Qualitätsmerkmale von Präsentationen; Medienkompetenz Präsentation und Medienkompetenz 02.05 Stärken-/Schwächenanalyse schade um die gute alte SWOT-Analyse 03.01 Funktionale, ökonomische, ökologische, soziale Aspekte Funktionale, ökonomische und ökologische Aspekte, z. B. Ergonomie, Leistungsparameter, einmalige und laufende Kosten, Nutzungsdauer, Energieverbrauch, Recyclingfähigkeit 03.01 Hardwareprodukte, z. B. CPU, Motherboard, Speicher, Datenspeicher, Netzteile, Grafikkarte, Peripheriegeräte, Netzwerkkomponenten, WLAN Hardwareprodukte, z. B. CPU, Motherboard, Speicher, Datenspeicher, Netzteile, Grafikkarte, Peripheriegeräte, Sensoren, Netzwerkkomponenten wie z. B. WLAN-Router, Switch, Gateway, Accesspoint das IoT lässt grüßen 03.01 Standardsoftware, z. B. Office-Pakete, Datenbank-Managementsysteme, Browser 03.01 Branchensoftware, z. B. ERP-Systeme, Supply Chain Management, Customer Relationship 04.03 ich hätte schwören können, dass das vorher schon drin stand x 03.01 Systemsoftware 03.01 Entwicklungssysteme, z. B. Compiler, virtuelle Maschinen, Interpreter, Editoren und Debugger 04.06 03.01 KI-Software ok, wir haben es verstanden, KI ist wichtig x 03.01 Cloudlösungen (Software as a Service, Infrastructure as a Service, Platform as a Service) Cloudlösungen, z. B. Software as a Service, Desktop as a Service 03.01 Virtualisierungen Virtuelle Desktops (Cloud oder lokal) also keine virtuellen Server mehr!? 03.02 Einteilung und Klassifikation von Anwendungssystemen 03.01 damit waren wohl CRM usw. gemeint 03.02 Benutzeroberfläche 03.02 Datenbanksysteme 03.01 03.02 Kommunikationssysteme Kommunikationssysteme, z. B. Videokonferenzsysteme, Social-Media-Systeme Social Media ist fast so wichtig wie KI 03.02 Netzwerkkomponenten, z. B. Router, Switch, Accesspoint 03.01 03.02 Netzwerkprotokolle, z. B. OSI-Modell, DNS, SMB, NFS, SMTP/S, IMAP/S, HTTP/S, IPSEC, IP, TCP, UDP, SSH, DHCP, ARP, TLS Netzwerkprotokolle (z. B. Ethernet, IP, DNS) und OSI-Modell die Liste der vorher aufgezählten Protokolle veraltet wohl zu schnell 03.02 Client-Server-Systeme spannend, dass so ein grundlegender Inhalt vorher fehlte 03.02 Einbindung in einer Domäne 03.02 Mobile Geräte, z. B. Smartphone, Tablet 04.02 03.03 Kenngrößen, Leistungsdaten, Funktionsumfang, z. B. BIOS, UEFI, CPU, RAM, Datenspeicher, RAID, Filesysteme, Grafikkarte, Netzwerkkarte, Router, Switch, LWL, Ethernet Standards, WLAN Standards Kenngrößen, Leistungsdaten, Funktionsumfang, z. B. Einstellungsmöglichkeiten im BIOS, UEFI, CPU, RAM, Datenspeicher (SSD/HDD), Filesysteme (z. B. FAT32, NTFS, APFS, ext4), Grafikkarte, Netzwerkkarte, Gateway/Router, Switch, LWL, Ethernet Standards, WLAN-Standards goodbye RAID, hello SSD x 03.03 Barrierefreier Zugriff auf IT-Systeme Barrierefreier Zugriff auf IT-Systeme am Arbeitsplatz, z. B. Einstellungsmöglichkeiten auf Webseiten da hat wohl jemand was vom Barrierefreiheitsstärkungsgesetz gehört x 03.03 Übertragungsraten, -Zeiten, Datenmengen von digitalisierten Dokumenten, Videos usw. war gefühlt in jeder Prüfung, aber stand noch nie im Katalog x 03.04 Auslastung und Anpassungsfähigkeit/Erweiterbarkeit, Zukunftssicherheit 03.04 Wertschöpfung 04.01 Lasten- und Pflichtenheft Lasten- und Pflichtenheft (Zweck, Urheber, Inhalt) 04.01 Installation und Einrichtung von Systemen, z. B. Betriebssysteme, BIOS, UEFI, Partitionierungen/Formatierungen, Netzwerkanbindungen, IP-Konfiguration, Remotedesktop Installation und Einrichtung von Systemen, z. B. Betriebssysteme, BIOS, UEFI, Partitionierungen/Formatierungen, Netzwerkanbindungen, IP(v4/v6)-Konfiguration, Remote-Desktop, KI-Software klein und unscheinbar haben die hier IPv6 reingeschmuggelt x 04.02 Geräteklassen, z. B. Desktops, Notebooks, Tablets, Smartphones Geräteklassen, z. B. Desktops, Notebooks, All-in-One, Thin Clients, Tablets, Smartphones 04.02 Mobile und stationäre Arbeitsplatzsysteme wie PC, Terminals, LAN, WLAN, mobiler Datenfunk (LTE/5G) Mobile und stationäre Arbeitsplatzsysteme wie PC, Terminals, LAN, WLAN warum LTE und 5G rausfliegt, kann ich nicht nachvollziehen x 04.02 Barrierefreiheit, z. B. Arbeitsplatz mit zweitem Monitor ausstatten, Lautsprecher/Mikrofon zur Verfügung stellen Barrierefreiheit, Unterstützung durch zusätzliche Hardware, z. B. größerer Monitor, breitere Tastatur, Lautsprecher/Mikrofon zur Verfügung stellen 04.03 Betriebssysteme Betriebssysteme (Einsatzzweck, Filemanagement, Freigaben managen) der Punkt war vorher auch viel zu umfangreich 04.03 Branchensoftware 03.01 04.03 KI-Software wir haben es jetzt verstanden! 04.04 Grundlagen des Schutzes der Urheber 04.05 Konsolenbefehle für Dateioperationen und Netzwerktroubleshooting, z. B. dir, Is, mkdir, ipconfig, ifconfig, alias, iproute2, arp, del, cp, copy, chmod, ping, traceroute Konsolenbefehle für Dateioperationen und Netzwerktroubleshooting, z. B. dir, Is, mkdir, ipconfig, ifconfig/ip, alias, iproute2, arp, del, cp, copy, chmod, ping, traceroute, nslookup ip und nslookup hätte ich früher erwartet 04.06 Klassen, Vererbung, Methoden Klassen, Attribute, Objekte, Methoden, Sichtbarkeit ui, endlich private und public in der AP1, aber dafür keine Vererbung mehr x 04.06 Skriptsprachen, z. B. Shell-Skript, Macros Skriptsprachen, z. B. Shell-Skript 04.07 Abbildung der Kontrollstrukturen mittels Struktogramm, PAP oder Pseudocode als didaktisches Hilfsmittel Abbildung der Kontrollstrukturen, z. B. Verzweigungen, Schleife, mittels Pseudocode goodbye Struktogramm und PAP x 04.07 UML (Use Case, Klassendiagramm) UML (Use Case bzw. Anwendungsfalldiagramm, Klassendiagramm, Aktivitätsdiagramm) hello Aktivitätsdiagramm x 04.07 Entwurf der Bildschirmausgabemasken (Softwareergonomie, Barrierefreiheit) Entwurf der Bildschirmausgabemasken (Softwareergonomie, Corporate Identity, Barrierefreiheit) 04.07 Fehler in einem gegebenen Quellcode finden alle ITler:innen sollten Quellcode verstehen x 04.07 Schreibtischtest mit einem gegebenen Quellcode durchführen x 04.08 Grundlagen von Datenbanken kennen und anwenden können Grundlagen von relationalen Datenbanken kennen und anwenden können goodbye NoSQL x 04.08 SELECT bezogen auf eine Tabelle goodbye SQL x 05.01 Qualitätsbegriff nach ISO 9000 05.01 Audit 05.02 Maßnahmen zur Verbesserung der Prozessqualität 05.02 Maßnahmen zur Verbesserung der Arbeitsqualität 05.02 Maßnahmen zur Verbesserung der Produkt- und Dienstleistungsqualität 05.02 Kriterien der Softwarequalität, Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit, Übertragbarkeit zugegeben, das war sehr FIAE-lastig x 05.02 Testprotokoll für das Einrichten eines Arbeitsplatzes was soll das sein? x 06.01 Gewährleistung von Verfügbarkeit, Vertraulichkeit und Integrität der Daten die Schutzziele wurden vorher tatsächlich nicht genannt x 06.01 organisatorische Maßnahmen, z. B. IT-Sicherheitsbeauftragter im Betrieb, Erstellung einer IT-Sicherheitsrichtlinie, z. B. Passwort-Policy Technisch organisatorische Maßnahmen (TOM); Unterscheidung von IT-Sicherheitsbeauftragtem und Datenschutzbeauftragtem im Betrieb; Erläuterung von IT-Sicherheitsrichtlinien wie Passwort-Policy 06.01 technische Maßnahmen, z. B. Virenschutzsystem, Firewall, Anti-Spam Benennung von technischen Maßnahmen, z. B. Virenschutz, Personal Firewall, Verschlüsselung (inkl. Unterscheidung symmetrisch, asymmetrisch und hybrid) 06.04 anscheinend sind nur noch Personal Firewalls relevant 06.01 personelle Maßnahmen, Sicherheitsbewusstsein herstellen personelle Maßnahmen, Entwicklung des Sicherheitsbewusstseins 06.01 Normen und Branchenstandards zur Informationssicherheit, Z. B. 06.01 ISO 2700x ich finde keine ISO-Norm mehr im neuen Katalog 06.01 BSI IT-Grundschutz Auszüge aus BSI IT-Grundschutz-Kompendium das ganze Ding hat ja auch mehrere hundert Seiten 06.01 Datenschutzgesetze national und auf EU-Ebene, z. B. DSGVO, BDSG Einhaltung der Grundzüge der Datenschutzgesetze, national und auf EU-Ebene, z. B. DSGVO, BDSG überprüfen auch diese Gesetze sind sehr umfangreich 06.01 Rechte der Betroffenen, Konsequenzen der Einwilligung der Betroffenen kennen x 06.01 Maßnahmen wie Anonymisierung und Pseudonymisierung x 06.02 Schutzbedarfsanalyse im eigenen Arbeitsbereich durchführen Schutzbedarfsanalyse im eigenen Arbeitsbereich aufgrund betrieblicher Vorgaben nach BSI IT-Grundschutz durchführen 06.02 Räume Räume, Infrastruktur 06.03 Schutzbedarfskategorien (normal, hoch, sehr hoch) Schutzbedarfskategorien (normal, hoch, sehr hoch) ableiten und begründen 06.03 IT-Sicherheitsmanagementsystem implementieren Informations-Sicherheitsmanagementsystem (ISMS) kennen und unterstützen 06.03 Betrieblicher IT-Sicherheitsbeauftragter 06.01 06.03 Risiko-Klassifikation, z. B. mit Matrix 06.04 Sicherung der Verfügbarkeit, z. B. RAID-Systeme, SAN Sicherung der Verfügbarkeit, z. B. NAS goodbye RAID und SAN x 06.04 Verschlüsselungstechniken, symmetrische und asymmetrische Verschlüsselung, CAs, Zertifikate, Digitale Signaturen, Techniken wie https, TLS Verschlüsselungstechniken kennen (symmetrische, asymmetrische und hybride Verschlüsselung); Hashwerte, Zertifikate und digitale Signaturen verwenden Hashes wurden vorher tatsächlich auch nicht erwähnt x 06.04 Authentifizierung, Passwort-Policy Authentifizierung (z. B. Zweifaktor) kennen, Passwort-Policy bewerten 06.04 Firewall, SSH vs. Telnet Personal Firewall anpassen, z. B. Softwarezugriff auf Internet sperren 06.04 Härtung Betriebssystem (Schwachstellen schließen) das ist sinnvoll x 07.01 Vertragsbestandteile, z. B. Leistungsbeschreibung, Termine, Entgelte, Lasten- und Pflichtenheft, Konventionalstrafen Vertragsbestandteile, z. B. Leistungsbeschreibung, Termine, Entgelte, Sanktionen/Konventionalstrafen 07.01 Verzug Vertragsstörungen nicht mehr nur der Verzug ist wichtig x 07.02 Ökologisch Ökologisch, z. B. Ressourcenschonung, Nachhaltigkeit 07.02 Ökonomisch (z. B. prozentuale Marge) Ökonomisch, z. B. Umsatz und Gewinn 07.02 Sozial Sozial, z. B. Arbeitsbedingungen 07.03 Abstimmen der dokumentierten Vorgaben zur Leistungserbringung während des gesamten Zeitraums mit dem Auftraggeber da konnte ich mir eh nie etwas drunter vorstellen 07.03 Kontinuierliche Prüfung der vertraglich vereinbarten Vorgaben 07.03 Berücksichtigung der Stilllegung von Altsystemen und Inbetriebnahme der neuen Systeme 07.03 Aufbewahrung von Archivdaten 07.03 Vollständige Dokumentation der erbrachten Leistung 07.04 Kauf, Miete, Leasing 03.04 07.04 Rolloutprozesse 07.04 Vorbereitung (Kunden-Onboarding, Scope festlegen, Formalitäten); 07.04 Rolloutumsetzung (Integration von Schnittstellen, kundenspezifische Entwicklungen) 07.04 Ticketsystem 01.03 07.04 Einhaltung des Budgets als ob sich ITler für Budgets interessieren 07.07 Inhalt des Abnahmeprotokolls, z. B. Gegenstand der Abnahme; Beteiligte Personen; Ort, Datum und Uhrzeit Inhalt des Abnahmeprotokolls 07.07 Arten der zu übergebenden Dokumentation, z. B.; Benutzerdokumentation (Handbuch); Schnittstellendokumentation; Programmdokumentation (Source-Code); Netzwerkdokumentation; Testprotokolle richtig so! niemand braucht Dokumentationen 07.07 Schlechtleistung, z. B. fehlende Funktionalität Schlechtleistung 07.07 Falschlieferung, z. B. falsche Softwarepakete ausgeliefert Falschlieferung 07.07 Minderlieferung, z. B. nur Teile der Software geliefert Minderlieferung 07.08 Bestätigung erbrachter Leistungen 07.08 Nachkalkulation 07.08 Generierung von Nachfolgeaufträgen

Literaturempfehlungen

Das hier sind die „offiziellen“ Prüfungskataloge für die vier Fachrichtungen des Fachinformatikers. Die Inhalte für AP1 sind natürlich überall identisch.

• Fachinformatiker / Fachinformatikerin – Anwendungsentwicklung Prüfungskatalog für die IHK-Abschlussprüfung
• Fachinformatiker / Fachinformatikerin – Systemintegration Prüfungskatalog für die IHK-Abschlussprüfung
• Fachinformatiker / Fachinformatikerin – Digitale Vernetzung Prüfungskatalog für die IHK-Abschlussprüfung
• Fachinformatiker / Fachinformatikerin – Daten- und Prozessanalyse Prüfungskatalog für die IHK-Abschlussprüfung

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Ich habe meine Themenliste zur AP1 natürlich passend zu den Änderungen aktualisiert: Mögliche Themen von Teil 1 der gestreckten Abschlussprüfung (GAP) in den IT-Berufen

Der Beitrag Neuer Prüfungskatalog für die AP1 der IT-Berufe ab 2025 – IT-Berufe-Podcast #190 erschien zuerst auf IT-Berufe-Podcast.

Die Unterscheidung von Lastenheft und Pflichtenheft ist Thema der einhundertneunundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Kurzübersicht Lastenheft

• Definition laut DIN 69901-5: „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“.
• Verfasst von: Auftraggeber, also aus Sicht des Kunden.
• Inhalt: Lösungsneutrale funktionale und nicht-funktionale Anforderungen an ein Produkt, eine zu erstellende Software oder ein Projektergebnis aus Sicht des Auftraggebers.
• Fragen: WAS soll erreicht werden? WARUM ist das wichtig? WOFÜR wird das benötigt? WER will das haben?
• Ziel: Basis, um Angebote von potenziellen Auftragnehmern einzuholen. Es bildet die Grundlage für das vom Auftragnehmer zu erstellende Pflichtenheft.
• Rechtliche Relevanz: keine
• Mögliche Inhalte
  • Anforderungen der Stakeholder (z.B. Fachlichkeit, Regualatorik, Usability, Performance, Hardware-/Netwerk-/Softwareumgebung)
  • Ist-Zustand und Soll-Zustand
  • Abnahmekriterien für die Prüfung, ob die Anforderungen erfüllt sind
  • Einschränkungen bei zu verwendenden Technologien
  • Anforderungen an den Auftragnehmer (z.B. Zertifizierung)
  • Schnittstellen
  • Sonstige Anforderungen (z.B. Dauer, Kosten, Meilensteine)

Kurzübersicht Pflichtenheft

• Definition laut DIN 69901-5: „vom Auftragnehmer erarbeitete[n] Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“.
• Verfasst von: Auftragnehmer, also aus Sicht des Dienstleisters.
• Inhalt: Vorschlag für technische Lösung der Anforderungen aus dem Lastenheft.
• Fragen: WIE sollen die Anforderungen umgesetzt werden? WELCHE Technologien kommen zum Einsatz?
• Ziel: Konkretes Angebot eines Auftragnehmers, um die Anforderungen aus dem Lastenheft des Auftraggebers zu erfüllen. Basis für die Kalkulation von Kosten/Aufwänden und das Erstellen eines Angebots. Definiert die Vorgaben für die spätere Implementierung.
• Rechtliche Relevanz: wird Vertragsbestandteil und dient zur Abnahme der erbrachten Leistung
• Mögliche Inhalte
  • Spezifikationen des geplanten Ergebnisses bzw. die technische Realisierung, z.B. Architektur, Technologien, UML-Diagramme, ER-Modelle, geplante Prozessabläufe, UI-Entwürfe
  • Entwicklungsprozess, Projektplan mit Meilensteinen, Vorgaben zur Kommunikation
  • Ressourcen wie konkrete Personen, Subunternehmen, Technologien

Definitionen aus dem IT-Handbuch

Beginnen wir mit einer Definition der Begriffe. Dafür schaue ich immer gerne in das IT-Handbuch*, das bis vor einigen Jahren noch der „offizielle“ Prüfungsbegleiter war und als Nachschlagewerk mit in die Prüfung genommen werden durfte. Dort werden Lasten- und Pflichtenheft wie folgt definiert:

Lastenheft

Das Lastenheft enthält alle Forderungen des Auftraggebers (Kunden) an die Lieferungen und/oder Leistungen eines Auftragnehmers. Die Forderungen sind aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Diese sollten quantifizierbar und prüfbar sein. Im Lastenheft wird definiert, was für eine Aufgabe vorliegt und wofür diese zu lösen ist.

Pflichtenheft

Das Pflichtenheft enthält das vom Auftragnehmer erarbeitete Realisierungsvorhaben auf der Grundlage des Lastenheftes. Das Pflichtenheft enthält als Anlage das Lastenheft. Im Pflichtenheft werden die Anwendervorgaben detailliert und in einer Erweiterung die Realisierungsforderungen unter Berücksichtigung konkreter Lösungsansätze beschrieben. Im Pflichtenheft wird definiert, wie und womit die Forderungen zu realisieren sind.

Gut verständlich finde ich auch die Erläuterungen in der Wikipedia, die sich auf die DIN 69901 stützen (die leider nicht kostenfrei verfügbar ist):

Lastenheft

Gemäß DIN 69901-5 […] beschreibt das Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“. Das Lastenheft beschreibt in der Regel somit, was und wofür etwas gemacht werden soll. [Herv. d. Verf.]

Pflichtenheft

Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt – das sogenannte wie und womit. […] Laut DIN 69901-5 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“. [Herv. d. Verf.]

Vor- und Nachteile von Lasten- und Pflichtenheft

• Gute Planungssicherheit für den Auftraggeber. Er weiß genau, was er bekommt und wie teuer es wird.
• Eher starres Vorgehen ist nur geeignet für Projekte, die für einen langen Zeitraum unverändert bleiben (Wasserfallmodell).
• Das Erstellen der Dokumente ist sehr aufwändig und zeitintensiv.
• In agilen Vorgehensmodellen wie Scrum werden sie nicht verwendet.
• Alternative: Arbeit in Inkrementen, Minimum Viable Product

Relevanz für die Praxis und die IHK-Projektarbeit

Lasten- und Pflichtenheft sind zwei Artefakte, die ich in (fast) jeder IHK-Projektdokumentation erwarte. Da die Abschlussprojekte eine genaue Zeitvorgabe haben (40 bzw. 80 Stunden) und auch die Anforderungen zu Beginn komplett feststehen (sollten), eignen sich Lasten- und Pflichtenheft gut für die Dokumentation der Anforderungen.

Wenn man eine Priorisierung durchführen müsste, würde ich mehr Gewicht auf das Pflichtenheft legen, da dieses die Grundlage für den Vertrag zur Erstellung der Software ist. Das heißt, die Abnahme am Ende des Projekts erfolgt „gegen“ das Pflichtenheft. Was dort nicht enthalten ist, wird auch nicht umgesetzt.

Das ist übrigens auch eine häufige Frage im Fachgespräch: Warum ist das Pflichtenheft so wichtig? Weil es Vertragsbestandteil ist. Die Abgrenzung zwischen Lasten- und Pflichtenheft wird übrigens auch gerne als Prüfungsfrage (schriftlich und mündlich) genommen.

Aber auch im realen Leben haben Lasten- und Pflichtenheft ihre Daseinsberechtigung in bestimmten Projekten, z.B. wenn es um sicherheitskritische Produkte geht, die nicht „mal eben“ agil entwickelt werden können/dürfen.

Wer erstellt das Lasten- und Pflichtenheft?

Wie die Definitionen oben nahelegen, sollte im Rahmen des IHK-Abschlussprojekts das Lastenheft vom Kunden bzw. der Kundin erstellt werden und das Pflichtenheft vom Prüfling. Der/die Kund:in formuliert, was er/sie gerne hätte (also die fachlichen Anforderungen), und der Prüfling definiert die dazu passende konkrete technische Lösung.

In der Praxis ist es allerdings häufig so, dass Kunden ihre Anforderungen gar nicht genau kennen, geschweige denn sie so formulieren können, dass ein:e ITler:in sie versteht. Daher spricht nichts dagegen, dass Prüflinge schon beim Erstellen des Lastenhefts mitarbeiten.

Wenn du genau in die Zeitplanung von Gerdas und Markus‘ Dokumentation schaust, wirst du feststellen, dass bei uns im Unternehmen genau so gearbeitet wird. Es wurde nämlich im Rahmen der Projektplanung Zeit für die Unterstützung des Fachbereichs bei der Erstellung des Lastenhefts eingeplant. Die Entwickler:innen helfen den Kunden z.B. bei der Formulierung der Anforderungen, aber auch bei deren Identifikation. Gute Methoden dafür sind z.B. Brainstorming oder Interviews.

Aufbau und Formulierung

Zu Inhalt, Aufbau und (gerade für die Projektdokumentation interessant) Formulierung von Lasten- und Pflichtenheft gibt es keine harten Vorgaben. Letztlich bestehen beide Artefakte aus Prosa.

Lastenheft

Ich persönlich würde einen etwas „moderneren“ Ansatz wählen und im Lastenheft User-Storys verwenden (für Beispiele verweise ich wieder auf die beiden obigen Dokumentationen). Durch diese Vorgabe wird man bei der einheitlichen Formulierung unterstützt und muss sich nicht alles neu ausdenken.

Es gibt aber auch andere Ansätze, wie z.B. die richtig „enterprisey“ Volere-Templates. Da ist allein das Inhaltsverzeichnis aller möglichen Anforderungen schon ellenlang.

Pflichtenheft

Das Pflichtenheft sollte dann natürlich einige konkrete technische Artefakte beinhalten, da es ja so spezifisch wie möglich sein muss. Ich beschreibe es immer gerne so: Das Pflichtenheft muss man einem/einer Softwareentwickler:in ohne Kommentar auf den Tisch legen können und er/sie entwickelt dann allein auf dieser Basis die gewünschte Software. Dass das in der Praxis so nicht funktioniert (und auch nicht meine präferierte Umgangsweise ist) ist hoffentlich klar.

Man kann aber durchaus alle in der Entwurfsphase erstellten Artefakte ins Pflichtenheft packen: Use-Case-Diagramm, Klassendiagramm, Komponentendiagramm, ERM, Tabellenmodell, GUI-Mockups, Testszenarien usw. Wie gesagt: Was nicht im Pflichtenheft steht, wird nicht umgesetzt (und nicht bezahlt).

Berücksichtigung in der IHK-Projektdokumentation

Da sowohl Lasten-, als auch Pflichtenheft recht lang werden können, empfehle ich, in der Projektdokumentation ausschließlich Ausschnitte daraus abzubilden. Und damit meine ich nicht Deckblatt und Inhaltsverzeichnis (habe ich leider schon oft so gesehen), sondern die konkreten Anforderungen bzw. Lösungsvorschläge. Also zeig bitte interessante Inhalte und nicht unwichtigen Kram.

Da die Seiten in der Projektdokumentation begrenzt sind, kann man vielleicht sogar zwei Fliegen mit einer Klappe schlagen und Lasten-/Pflichtenheft sowie projektrelevante technische Inhalte daraus in nur einem Anhang zeigen. Beispiel: Das Pflichtenheft enthält ein Komponentendiagramm der geplanten Anwendung. Dann könnte der einseitige Auszug aus dem Pflichtenheft (die Seiten mit dem Komponentendiagramm) im Anhang der Dokumentation sowohl im Kapitel „Architektur“, als auch im Kapitel „Pflichtenheft“ referenziert werden. Einmal wird eben auf das Diagramm verwiesen und einmal auf das Pflichtenheft als erstelltes Artefakt.

Ich persönlich würde aber eher die für die Artefakte spezifischen Inhalte zeigen, also die formulierten Anforderungen. Denn das ist der eigentlich interessante Inhalt der beiden Dokumente im Rahmen der Projektdokumentation. Gerda und Markus haben das auch so gemacht.

Fazit

Lasten- und Pflichtenheft sind zwei wichtige Artefakte, die sowohl im richtigen Leben, als auch in der IHK-Abschlussprüfung relevant sind. Schau dir die Definitionen und einige Beispiele in Ruhe an und lerne sie auch für die Prüfung.

Literaturempfehlungen

*

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Was? Pflichtenheft und Lastenheft sind nicht dasselbe?
• DIN 69901 – Wikipedia
• Lastenheft – Wikipedia
• Pflichtenheft – Wikipedia

Der Beitrag Lastenheft und Pflichtenheft – IT-Berufe-Podcast #189 erschien zuerst auf IT-Berufe-Podcast.

Um Teamarbeit bei der Softwareentwicklung geht es im Interview mit Christian Kranert in der einhundertachtundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Vorstellung Christian Kranert

Christian hat sich schon in Episode 164 des Podcasts über Softwarequalität ausführlich vorgestellt, aber hier noch einmal die wichtigsten Eckdaten.

• Christian Kranert
• seit 17 Jahren in der IT und Softwareentwicklung tätig
• angefangen mit Visual Basic 6 auf Windows 95
• Ausbildung zum Fachinformatiker für Anwendungsentwicklung absolviert
• viel im SAP-Umfeld mit ABAP entwickelt
• inzwischen hauptsächlich mit C# unterwegs
• lebt und arbeitet in Nürnberg bei Head On Solutions GmbH
• entwickelt dort Cloud-Software für lokale Geschäfte wie Friseur-Studios zum Planen von Terminen, Kassieren, Buchhaltung usw.
• ist Abteilungsleiter mit eigenem Team

Teamarbeit in der Softwareentwicklung

Warum brauchen wir Teamarbeit bei der Softwareentwicklung?

• bei der Komplexität heutiger Software ist es fast undenkbar, diese alleine zu entwickeln
• heutige Webanwendungen enthalten z.B. sehr viel UI-Entwicklung und sind im Backend und Frontend sehr komplex, Stichwort: Full Stack
• Christians Unternehmen hat ein eigenes Team ausgelagert nur für VueJS im Frontend
• durch das Team entsteht auch bessere Software
• wir wollen doch die „echte Welt“ übersetzen in Code und dort gibt es auch mehr als einen Benutzer
• gemeinsam zu entwickeln macht mehr Spaß, ist sozial, man kann voneinander lernen, man kann sich weiterentwickeln
• die interdisziplinäre Zusammenarbeit mit dem Fachbereich bzw. Kunden ist auch extrem wichtig

Wie sieht erfolgreiche interdisziplinäre Zusammenarbeiten zwischen dem IT-/Entwicklungs-Team und anderen Abteilungen aus?

• der Fachbereich erklärt den Entwickler:innen die Fachlichkeit
• Entwickler:innen dürfen/müssen das aber auch hinterfragen und ggfs. bessere Lösungen vorschlagen
• man sollte erst über das Problem reden und nicht schon über Lösung
• es muss die generelle Bereitschaft zur Teamarbeit vorhanden sein und eine entsprechende Kultur

Welche Prozessmodelle (z.B. Wasserfall, Scrum) unterstützen/behindern die Teamarbeit?

• das klassische Wasserfallmodell ist eher hierarchisch aufgebaut mit Lasten-/Pflichtenheft und passt nicht so gut zur Teamarbeit
• Scrum ist aber auch kein Allheilmittel
• das Daily ist sehr wichtig, denn Kommunikation ist der Schlüssel zu erfolgreicher Teamarbeit

Wie sieht richtig gute Teamarbeit in der Softwareentwicklung aus?

• Kommunikation ist das A und O, z.B. wenn ein Feature fertig ist, damit die Kolleg:innen darauf aufsetzen können
• alle Teammitglieder:innen sollten auch aktiv Hilfe anbieten und einfordern
• die gesamte Softwareentwicklung ist Teamarbeit und die geht schon mit der Produktidee los
• dabei kann es helfen, verschiedene Perspektiven einzunehmen, um ein besseres Bild der Anforderungen zu bekommen
• auch weitere Aufgaben lassen sich besser im Team lösen: Risiken abschätzen, Prioritäten ableiten, Product Backlog füllen
• wenn das Verhältnis von Kosten und Nutzen passt, startet die Implementierung und Aufgaben werden im Team verteilt
• in Christians Team werden Konzepte z.B. gemeinsam erarbeitet, ganz einfach in OneNote*
• das Team startet mit einem Datenmodell als Diskussionsgrundlage und legt dann die Datentypen fest
• außerdem werden Mockups erstellt, um darüber gemeinsam zu diskutieren
• sehr wichtig ist auch das gemeinsame Festlegen von Namen im Team, denn viele Köpfe haben mehr (fachliches) Wissen als einer alleine
• der große Vorteil bei dieser Vorgehensweise ist, dass früh erkannte Fehler bei Anpassungen wenig kosten im Vergleich zu späteren Projektphasen, wenn alles schon umgesetzt ist

Warum ist die Teamkultur nicht nur beim Code Review wichtig und wie sieht sie aus?

• Christians Team entwickelt oft im Pair Programming zusammen und führt danach noch Code Reviews durch
• hier war oft insb. beim Testen die Einstellung, dass das doch jemand anders macht und nicht die Aufgabe der Softwareentwickler:innen sei
• aber gerade beim Testen ist die Abstimmung mit den Tester:innen wichtig, damit man nicht den kompletten Code umschreiben muss, wenn man am Test vorbei entwickelt hat

Wie stellt man sicher, dass alle Teammitglieder:innen sich aktiv einbringen und wie kann eine Führungskraft Teamarbeit fördern/behindern?

• die Führungskraft ist sehr wichtig, denn ihre zentrale Aufgabe ist die Pflege der Teamkultur
• die häufig anzutreffene Skepsis bei Entwickler:innen gegenüber Meetings muss von der Führungskraft abgebaut werden
• Meetings müssen aber natürlich auch einen Mehrwert für alle Teilnehmer:innen bieten und müssen vernünftig geplant und vorbereitet werden
• auch für Entwickler:innen sind Meetings wichtig, da sie helfen, offene Fragen zu klären und Entscheidungen herbeizuführen
• Teamarbeit kann die Teammitglieder:innen motivieren, wenn man gemeinsam eine gute Lösung findet und z.B. eine „harte Nuss“ knackt

Braucht ein Team eine Leitung?

• das kommt stark auf das Team an

Storming, Forming, Norming, Performing: gibt es das wirklich in der Praxis?

• Christian hat das mal in einem Buch gelesen, aber nur dunkel in Erinnerung
• in der Praxis durchlaufen die Teams diese Phasen wohl tatsächlich, aber intuitiv verhalten sich die Mitglieder:innen meist den Phasen entsprechend

Wie sieht häufig die (negative) Realität in Sachen Teamarbeit aus bzw. an welchen Fehlern scheitert Teamarbeit häufig?

• Juniors werden vernachlässigt und bekommen keine oder zu wenig Unterstützung
• Hierarchiedenken, gerade wenn Softwareentwicklung nicht das Kerngeschäft des Unternehmens ist
• Introvertiertheit der Teammitglieder:innen
• aber auch Extrovertiertheit bzw. Egozentrik bei Teammitglieder:innen
• Mangel an Diversität im Team

Wie wird man als Entwickler:in „teamfähig“?

• Persönlichkeitsentwicklung! dazu gibt es viele gute Bücher
• eine fördernde und fordernde Führungskraft ist wichtig für das Empowerment der Teammitglieder:innen
• die Führungskraft sollte z.B. One-on-Ones mit Mitarbeitenden führen, immer wieder nachfragen und auch die eigene Entwicklung aufzeigen
• loben und wertschätzen sollten bei jeder Führungskraft dazu gehören
• Empathie ist auch wichtig
• Konflikte sollten schnell gelöst werden

Wie wichtig ist eine gute Fehlerkultur?

• sehr wichtig
• Fehler müssen erlaubt sein und dürfen nicht „geahndet“ werden
• aber was ist eigentlich ein Fehler? Schludrigkeit ist sicherlich kein Fehler
• Checklisten können helfen, eine gewisse Basisqualität sicherzustellen

Wie können schon Azubis in die Teamarbeit integriert werden?

• einfach mal loslegen und sie an die Hand nehmen
• Azubis direkt in echte Projekte einbinden, aber ohne harten Deadlines oder großes Fehlerpotential
• viel loben
• Checklisten helfen auch hier beim Einstieg

Was sind die Folgen, wenn nicht im Team gearbeitet wird?

• Christian hat noch nie jemanden kennengelernt, der/die sich aktiv gewehrt hat gegen Teamarbeit
• eher haben die Kolleg:innen evtl. Angst mitzumachen
• den berühmten „10x-Develover“ gibt es nicht, aber Seniors können als Multiplikatoren im Team wirken und Juniors voranbringen und damit das gesamte Team

Wie/wo kann man dich erreichen?

• LinkedIn

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Qualitätssicherung bei der Softwareentwicklung mit Christian Kranert
• Christian Kranert bei LinkedIn
• Head-on Solutions GmbH bei LinkedIn

Der Beitrag Teamarbeit bei der Softwareentwicklung mit Christian Kranert – IT-Berufe-Podcast #188 erschien zuerst auf IT-Berufe-Podcast.

Um Datenbanktransaktionen, die ACID-Prinzipien und Alternativen dazu geht es in der einhundertsiebenundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Datenbanktransaktionen sollten jedem/jeder ITler:in etwas sagen, da wir fast täglich mit datenbankgestützten Anwendungen arbeiten, egal, ob wir selbst diese Anwendungen programmieren oder „nur“ Abfragen gegen eine Datenbank durchführen.

Was ist eine Datenbanktransaktion?

Eine Transaktion ist eine Menge aus mehreren zusammenhängenden Datenbankoperationen, die gemeinsam als eine Einheit durchgeführt werden müssen.

Beispiele für Datenbanktransaktionen:

• Banküberweisung von 100 EUR von Konto DE123 auf Konto DE432
  • UPDATE konto SET kontostand = kontostand - 100 WHERE iban = 'DE123';
  • UPDATE konto SET kontostand = kontostand + 100 WHERE iban = 'DE432';
• Neuen Tag katze zu einem Blog-Post mit ID 123 hinzufügen
  • INSERT INTO tag (id, name) VALUES (1, 'katze');
  • INSERT INTO tag_post (post_id, tag_id) VALUES (123, 1);
• Neue Bestellung für einen Kunden mit ID 324 erfassen für Artikel 253
  • INSERT INTO bestellung (id, datum, kunde_id) VALUES (123, '2024-04-10', 324);
  • INSERT INTO bestellposition (bestellung_id, artikel_id, menge, preis) VALUES (123, 253, 1, 123.92);
• Neuen Tarifsatz einer Versicherung anlegen und bisherigen beenden
  • UPDATE tarif SET gueltig_bis='2024-04-10' WHERE id=122;
  • INSERT INTO tarif (id, gueltig_ab, beitrag) VALUES (123, '2024-04-10', 143.23);

Begriffsabgrenzung

Eine Datenbanktransaktion ist nicht zu verwechseln mit einer Transaktion im Geschäftsbetrieb, z.B. einer Überweisung bei einer Bank, dem Kauf eines Autos oder der Buchung eines Fluges.

Die ACID-Prinzipien

Datenbanktransaktion müssen/sollen bestimmten Kriterien genügen, die als ACID-Prinzipien bekannt sind.

• Atomarität/Atomicity: Alle Datenbankoperationen werden entweder vollständig gemeinsam durchgeführt oder gar nicht. Es kann nicht sein, dass nur einige Operationen durchgeführt werden und andere nicht. Dazu werden die Datenbankoperationen in eine Transaktion „eingeklammert“.
  • Beispiel: Bei der Banküberweisung darf nicht nur Geld abgebucht oder gutgeschrieben werden, sondern beide Buchungen müssen gemeinsam durchgeführt werden.
• Konsistenz/Consistency: Wenn die Datenbank vor der Transaktion in einem konsistenten Zustand war, dann muss sie es auch nach der Transaktion sein.
  • Beispiel: Bei der Banküberweisung bleibt der Gesamtbetrag an Geld gleich. Es entsteht kein Geld aus dem Nichts und es geht auch kein Geld verloren.
• Isolation/Isolation: Mehrere Transaktionen dürfen sich nicht gegenseitig beeinflussen. Hierzu folgen weiter unten verschiedene Maßnahmen zur Umsetzung.
  • Beispiel: Bei zwei parallelen Banküberweisungen vom gleichen Konto müssen beide Beträge nacheinander abgebucht werden und nicht nur der der zuletzt durchgeführten Transaktion.
• Dauerhaftigkeit/Durability: Die Daten müssen nach Abschluss der Transaktion persistent gespeichert sein und z.B. auch einen Systemausfall überstehen. Das wird durch sogenannte Transaktionslogs sichergestellt.
  • Beispiel: Wenn nach dem Abschluss einer Transaktion der Datenbankprozess abstürzt, müssen auch nach dem Neustart der Datenbank die aktualisierten Daten vorhanden sein.

Maßnahmen zur Wahrung der Isolation von Transaktionen

Wenn Transaktionen nicht isoliert voneinander ablaufen, können verschiedene Probleme in der Datenbank auftreten.

• Dirty Read: Veränderte Daten einer noch offenen Transaktion werden von einer anderen Transaktion gelesen und weisen somit einen „dreckigen“ Zustand auf, weil er noch nicht final ist.
  • Beispiel: Bei einem Ticketkauf geht die zweite Buchung schon vom veränderten Bestand der ersten Transaktion aus.
• Lost Updates: Wenn zwei Transaktionen gleichzeitig denselben Datensatz verändern, „gewinnt“ die Änderung der zuletzt durchgeführten Transaktion und die der ersten ist verloren.
  • Beispiel: Bei zwei Banküberweisungen wird der Kontostand auf den Ursprungsstand abzgl. der zweiten Überweisung gesetzt, aber ohne die erste Überweisung abzuziehen.
• Non-Repeatable Read: Wiederholte Lesevorgänge innerhalb einer Transaktion liefern unterschiedliche Ergebnisse.
  • Beispiel: Bei einer Flugbuchung wird geprüft, ob noch ausreichend Plätze frei sind, aber durch eine parallele Buchung wird bei der zweiten Abfrage ein unterschiedliches Ergebnis geliefert.
• Phantom Read: Während eine Transaktion Datensätze nach einem bestimmten Kriterium liest, werden weitere Datensätze zum gleichen Kriterium hinzugefügt/gelöscht/verändert.
  • Beispiel: Während der Durchschnittsberechnung von Gehältern von Mitarbeiter:innen wird ein neuer Mitarbeiter hinzugefügt, der beim Summieren des Gehalts noch nicht berücksichtigt wird, aber beim Zählen der Datensätze dann schon.

Die Datenbank kann verschiedene Transaktionsisolationsebenen implementieren, um den obigen Problemen entgegenzuwirken. Grundsätzlich werden dabei Sperren verwendet, um die gleichzeitige Verarbeitung der Daten einzuschränken. Es kann dabei eine Lesesperre und/oder eine Schreibsperre gesetzt werden, wodurch das gleichzeitige Lesen bzw. Schreiben eingeschränkt wird.

• Read Uncommitted: Es werden keine Sperren verwenden. Quasi kein Schutz vor obigen Problemen. Vergleichbar mit NO ACTION bei referenzieller Integrität.
• Read Committed: Für die gesamte Transaktion werden Schreibsperren auf alle beteiligten Objekte gesetzt, die verändert werden sollen. Lesesperren werden aber nur kurzzeitig gesetzt. Es können Non-Repeatable Read und Phantom Read auftreten.
• Repeatable Read: Es werden für die gesamte Transaktion Lese- und Schreibsperren auf alle beteiligten Objekte gesetzt. Nur Phantom Reads können noch auftreten (weil dabei zwei lesende Operationen mit unterschiedlichen Kriterien durchgeführt werden).
• Serializable: Die Datenbank verhält sich so, als würden die Transaktionen komplett separiert nacheinander („seriell“) durchgeführt. Dabei kann keines der obigen Probleme mehr auftreten, aber Transaktionen müssen ggfs. abgebrochen werden. Starten z.B. zwei Flugbuchungen für zwei Sitzplätze parallel auf dem Sitzplatzbestand von 2, wird die erste Transaktion den Bestand auf 0 reduzieren und die zweite Transaktion (die „gewartet“ hat) muss abbrechen, weil die Sitzplätze nun nicht mehr ausreichen.

Umsetzung in SQL

Mit der Transaction Control Language (TCL) gibt es eine eigene Familie an SQL-Befehlen, die sich nur um die Transaktionssteuerung kümmert. Hiermit können Datenbankoperationen zu einer Transaktion zusammengefasst werden.

• BEGIN TRANSACTION: Startet eine Datenbanktransaktion.
• COMMIT: Beendet eine Datenbanktransaktion und schreibt die Änderungen fest.
• ROLLBACK: Rollt eine Datenbanktransaktion zurück und verwirft alle Änderungen.

In vielen Datenbanken muss man nicht explizit Transaktionen starten und beenden. Sie verwenden ein sogenanntes Auto-Commit. Dabei wird jedes Statement in einer eigenen Transaktion durchgeführt.

Umsetzung in ORMs

Brauche ich als Softwareentwickler:in überhaupt Wissen über Datenbanktransaktionen? In modernen Entwicklungsprojekten werden doch sowieso objektrelationale Mapper (ORM) verwendet. Doch auch diese ORMs können natürlich nicht zaubern, sondern verwenden unter der Haube die normalen Datenbankoperationen. Daher ist auch bei Verwendung eines ORMs wichtig zu wissen, welche Operationen in einer gemeinsamen Transaktion durchgeführt werden müssen.

Dafür bieten viele ORMs entsprechende Befehle an. Jakarta EE hat sogar einen eigenen Standard dafür: Jakarta Transactions (JTA). Dort wird z.B. Annotation @Transactional verwendet. Diese wird an eine Java-Methode geschrieben, die dann automatisch innerhalb einer Datenbanktransaktion ausgeführt wird. Im Fall einer aufgetretenen Exception wird dabei dann automatisch ein Rollback durchgeführt.

CAP und BASE

Transaktionen nach den ACID-Prinzipien sind ein wichtiger Bestandteil vieler Datenbanksysteme. Sobald die Datenbank jedoch auf mehrere Knoten verteilt wird, können Transaktionen zu einem Problem werden. Das sogenannte CAP-Theorem besagt, dass es in einem verteilten System nicht möglich ist, alle drei Eigenschaften Konsistenz, Verfügbarkeit und Ausfalltoleranz gleichzeitig zu garantieren.

• Konsistenz (Consistency): Die Konsistenz meint in diesem Kontext den einheitlichen Datenstand über alle Datenbankknoten hinweg (und nicht die Konsistenz vor/nach einer Transaktion). Egal, welcher Knoten abgefragt wird, es werden immer die gleichen Daten zurückgegeben.
• Verfügbarkeit (Availability): Die Datenbank antwortet in akzeptabler Zeit auf alle Anfragen. Dabei kann es jedoch sein, dass nicht immer die aktuellsten Daten geliefert werden.
• Partitionstoleranz (Partition tolerance): Die Datenbank arbeitet auch weiter, wenn einzelne Knoten ausfallen.

Angenommen, die verteilte Datenbank soll zu jedem Zeitpunkt in einem konsistenten Zustand sein (also alle Informationen auf allen Knoten sollen identisch sein), dann führt ein Ausfall eines Knoten automatisch dazu, dass eine Transaktion fehlschlagen muss, da der ausgefallene Knoten nicht sofort aktualisiert werden kann. Die Konsistenz wäre dann zwar gewährleistet, aber die Partitionstoleranz nicht.

Da heutzutage viele Anwendungen tatsächlich mit verteilten Datenbanken arbeiten, wurde mit BASE ein Gegenentwurf zu ACID geschaffen. Das Wort ist etwas konstruiert, um das Gegenstück zu ACID zu bilden. Aus der Chemie kennen wir den Unterschied zwischen Säure („acid“) und Lauge („base“). Im Kern stellt ACID die Konsistenz eines Systems sicher, während BASE die Verfügbarkeit in den Vordergrund stellt.

• Basically Available: Die Datenbank ist grundsätzlich für alle Benutzer jederzeit erreichbar (hohe Verfügbarkeit).
• Soft state: Daten können sich im Laufe der Zeit verändern und temporäre („weiche“) Zustände annehmen, wenn mehrere Änderungen parallel durchgeführt werden.
• Eventual consistency: Irgendwann einmal werden die Daten in der Datenbank einen konsistenten Zustand erreichen. Bis dahin können Anfragen unterschiedliche Ergebnisse produzieren.
  • Vorsicht „false friend“: „eventually“ heißt auf Deutsch „schlussendlich“ und nicht „eventuell“. Es wird also immer Konsistenz erreicht, nur eben nicht unmittelbar sofort.

Literaturempfehlungen

*

In Kapitel 13 gibt es eine gute und kurze Einführung in das Thema Datenbanken inkl. Transaktionen. Ich habe das Kapitel auch schon im Buchclub besprochen: Buchclub: Handbuch für Fachinformatiker (Teil 11: Datenbanken)

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• ACID – Wikipedia
• Isolation (Datenbank) – Wikipedia
• START TRANSACTION, COMMIT, and ROLLBACK Statements
• autocommit, Commit, and Rollback
• Jakarta Transactions 2.0
• Annotation @Transactional in Jakarta EE
• CAP-Theorem – Wikipedia
• Unterschied zwischen ACID- und BASE-Datenbanken

Der Beitrag Datenbanktransaktionen, ACID, CAP-Theorem und BASE – IT-Berufe-Podcast #187 erschien zuerst auf IT-Berufe-Podcast.

Um die angemessene fachliche bzw. technische Tiefe des Themas für das IHK-Abschlussprojekt für Anwendungsentwickler:innen geht es in der einhundertsechsundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Viele Projektanträge zum Abschlussprojekt werden abgelehnt, weil das umzusetzende Projekt nicht die nötige fachliche bzw. technische Tiefe aufweist. In unserem Prüfungssystem gibt es dafür sogar einen expliziten Ablehnungsgrund. Doch was heißt es genau, dass die fachliche Tiefe nicht erreicht wurde? Welche fachliche Tiefe ist überhaupt angemessen und wie erkenne ich als Prüfling, ob ich sie erreiche?

Mein Standardbeispiel: Projektverwaltung

Ich führe als Beispiel für eine übliche Projektarbeit für Anwendungsentwickler:innen immer eine klassische Web-Anwendung an. Nehmen wir das oft strapazierte Beispiel einer Zeiterfassungssoftware oder einer Projektverwaltung. Dabei handelt es sich um eine kleine Web-Anwendung mit ein paar Datenbanktabellen, etwas fachlicher Logik und ein paar netten Oberflächen.

In solch einer Anwendung kann ich als Anwendungsentwickler:in alles zeigen, was ich in meiner dreijährigen Ausbildung gelernt haben sollte. Soll ich ein Projekt enpfehlen, führe ich deswegen gerne dieses Beispiel für ein fachlich ausreichendes Projekt für die Abschlussprüfung an.

• Ich kann eine Datenbank modellieren, z.B. mit einem ERM oder Tabellenmodell.
• Ich kann ein Klassendesign entwerfen, z.B. mit einem Klassendiagramm oder gar mit Test Driven Development.
• Ich kann die Oberflächen gestalten, natürlich nach ergonomischen Gesichtspunkten und mit Mockups für den ersten Entwurf.
• Außerdem muss ich mich um das Zusammenspiel der Komponenten kümmern und brauche dafür eine tragfähige Architektur, z.B. MVC.

Kurz gesagt ist in solch einem Projekt alles Technische enthalten, was man heutzutage in der Programmierung können muss. Und ich kann mich vieler Methoden der Softwareentwicklung bedienen, die mein planvolles Vorgehen dokumentieren.

Hast du auch ein paar konkrete Zahlen?

Als ganz grobe Daumenregel für Anwendungsentwickler:innen führe ich immer ein „klassisches“ Webprojekt an: kleine Datenbank, ein bisschen Logik, Frontend drüber. Da kann man das volle Spektrum der Entwicklungstätigkeiten zeigen.

• ca. fünf Datenbanktabellen („eine Hand voll“)
• ca. fünf Oberflächen dazu
• ca. zehn Klassen (tendenziell eher mehr)

Sollte die Anwendung eine komplizierte Logik umsetzen, kann natürlich bei den anderen Komponenten entsprechend gekürzt werden. Diese grobe Richtlinie ist sicherlich nicht allgemeinverbindlich. Es kommt immer auf den Einzelfall an. Ich möchte nur deutlich machen, dass eine triviale Konsolenapplikation, die eine Textdatei einliest und wieder speichert, nicht ausreicht. Es sei denn, die Applikation verwendet dafür einen selbst programmierten Verschlüsselungsalgorithmus.

Die Diagramme aus dem Titelbild dieser Episode sollten offensichtlich zeigen, dass dieser Umfang für ein Abschlussprojekt nicht ausreicht! Aber ich habe schon Artefakte in echten Dokus gesehen, die nicht viel umfangreicher waren (z.B. nur zwei Use-Cases oder drei Aktivitäten).

Brauche ich alle Komponenten – Datenbank, Logik, UI?

Das heißt nicht, dass jedes Abschlussprojekt alle genannten Komponenten umfassen muss. Nicht alle Unternehmen haben die Anforderung, Weboberflächen über Datenbanken zu gestalten. In vielen Betrieben wird eine bestehende Software erweitert, eine Oberfläche angepasst, oder eine Datenbank um zusätzliche Tabellen erweitert. Oft werden auch Programme benötigt, die gar keine grafische Oberfläche haben. Wenn es z.B. um den Datenabgleich zwischen ERP-System und Webshop geht, der nachts als Batchjob laufen soll, ist es völlig unnötig, eine schön gestaltete grafische Oberfläche dazu zu entwickeln. Auch werden inzwischen oft REST-APIs als Abschlussprojekt erstellt, die natürlich auch nicht von Menschen bedient werden. Daher ist es völlig legitim, auf die ein oder andere Komponente im Abschlussprojekt zu verzichten.

Auch heißt es umgekehrt nicht automatisch, dass man ein fachlich ausreichendes Projekt hat, nur weil alle Schichten Berücksichtigung finden. Eine Weboberfläche mit einem Formular, die simple CRUD-Operationen gegen eine Datenbanktabelle durchführt, ist selbstverständlich nicht umfangreich genug.

Mein Anti-Beispiel: SAP-Projekte

Dieses Problem haben meiner Erfahrung nach oftmals die Anwendungsentwickler:innen im SAP-Umfeld. Hier wird häufig nur sehr wenig tatsächlicher Code produziert, sondern viel mehr Zeit für die hochkomplexe Infrastruktur verbraten. Da gehen allein schon 7 Stunden drauf, bis man den richtigen Einstiegspunkt in die „Transaktion“ (oder wie auch immer das dort heißt) gefunden hat. Und die meisten Inhalte lassen sich dann mit SAP-Mitteln generieren, sodass der Entwickler eigentlich fast gar nichts mehr tun muss.

In eine ähnliche Richtung gehen heutzutage immer mehr die Low-Code- oder No-Code-Plattformen. Da wird kaum selbst programmiert, sondern einfach was zusammengeklickt. Und da muss ich mich dann schon fragen lassen, wie ich „Anwendungsentwickler:in“ werden will, wenn ich gar keine Anwendung entwickle.

Aber es gibt auch Negativbeispiele aus anderen Bereichen. Mein persönliches Highlight aus einer Abschlussprüfung war eine einzelne HTML-Seite, die mit 20 Zeilen JavaScript angereichert wurde. Das Problem war, dass der Prüfling selbst überhaupt nicht verstand, warum dieses Projekt nicht ausreichend war. Sein:e Ausbilder:in hatte ihn offensichtlich überhaupt nicht darauf vorbereitet. Und er war sehr enthusiastisch und freute sich richtig über sein Projekt. Das tat mir dann wirklich leid, da die Schuld für dieses unzureichende Projekt sicherlich nicht beim sehr motivierten Prüfling zu suchen war.

Methodik ist das A und O

Kurz gesagt sollte ein Abschlussprojekt zeigen, dass du methodisch Software entwickeln kannst, die eine gewisse Komplexität aufweist. Dazu habe ich in dieser Podcast-Episode noch viel mehr zu erzählen: Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung.

Es geht darum, dass du deine Fähigkeiten angemessen unter Beweis stellst. Du sollst methodisch Software entwickeln und die Projektarbeit wirtschaftlich umsetzen. Dazu gehört u.a. eine Betrachtung der Kosten und der Amortisation, der Einsatz von Modellierungs- oder Dokumentationsmethoden (z.B. ERM, UML, EPK, Mockups), das Erstellen sinnvoller Dokumentationen (z.B. für Kunden, Betrieb, Entwickler), das planvolle Vorgehen bei der Projektumsetzung (z.B. Projektplan, Iterationsplanung, Gantt-Chart), eine gute Qualitätssicherung (z.B. Unit-Tests, Abnahmeprotokoll) usw.

Individuelle Einschätzung

Wenn du dir nicht sicher bist, ob dein geplantes Programm als Abschlussprojekt ausreicht, dann frag deine:n Ausbilder:in oder deine:n Berufsschullehrer:in. Die sollten die nötige Erfahrung mitbringen und die Anforderungen der IHKen einschätzen können. Alternativ stell dein Projekt doch im Forum vor oder schreib mir eine Mail. Ich helfe dir gerne mit einer kurzen Einschätzung weiter – aber erst nachdem du diese Podcast-Episode gehört hast.

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung

Der Beitrag Angemessene fachliche/technische Tiefe des Abschlussprojekts für Anwendungsentwickler:innen – IT-Berufe-Podcast #186 erschien zuerst auf IT-Berufe-Podcast.

Um den sinnvollen Aufbau eines IHK-Abschlussprojekts für Fachinformatiker:innen Anwendungsentwicklung geht es in der einhundertfünfundachzigsten Episode des IT-Berufe-Podcasts.

Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung

Oft lese ich Projektdokumentationen für den Beruf Fachinformatiker:in Anwendungsentwicklung, die in sich einfach nicht stimmig sind. Der Projektablauf folgt keinem roten Faden und Artefakte werden wild durcheinandergewürfelt. Oft werden auch einfach nur Kapitel aus Dokumentationsvorlagen „ausgefüllt“, scheinbar ohne über ihre Sinnhaftigkeit nachzudenken.

In dieser Podcast-Episode gebe ich einen Überblick über einen – aus meiner Sicht – sinnvollen Ablauf eines IHK-Projekts im Bereich Anwendungsentwicklung inkl. möglicher Artefakte und ihrem Zweck. Dabei gehe ich nicht auf die Beschreibung des Projekts, die Wirtschaftlichkeitsbetrachtung, das Projektmanagement, die Ressourcenplanung usw. ein, sondern nur auf die Planung und Durchführung der eigentlichen Aufgabe: der Entwicklung einer Softwarelösung. Selbstverständlich gehören aber alle genannten Punkte auch in eine IHK-Projektdokumentation.

Wahl des Vorgehensmodells

Fast immer ist das Wasserfallmodell das einzig sinnvolle Vorgehensmodell, da das IHK-Projekt vom Prüfling alleine in einer fest vorgegebenen Zeit mit vorgegebenem (weil im Antrag genehmigten) Umfang umgesetzt werden muss.

Praxisbeispiele für unpassende Prozesse:

• Scrum gewählt, aber
  • klassische Wasserfallphasen durchgeführt/beschrieben
  • Lasten-/Pflichtenheft erstellt statt User Stories
  • Projekt alleine umgesetzt ohne Team/Scrum Master/Product Owner
  • gesamtes Projekt ist ein einziger Sprint
• XP gewählt, aber
  • keine Praktiken (z.B. Pair Programming, Test Driven Development) angewendet
• Kanban gewählt, aber
  • Lanes nur ToDo/Doing/Done

Artefakte methodisch sinnvoll einsetzen

• Software soll nicht einfach „runterprogrammiert“ werden, sondern methodisch entwickelt werden. Dabei helfen verschiedene Artefakte wie Entity-Relationship-Modelle, UML-Diagramme usw.
• Diagramme können oft auf zwei Arten eingesetzt werden: zur Modellierung (vor der Implementierung) und zur Dokumentation (nach der Implementierung). Sie haben keinen Selbstzweck, sondern sollen immer den jeweiligen Prozessschritt unterstützen.
• Ihr Einsatz muss zum gewählten Prozess passen. Ein Klassendiagramm zur Modellierung passt z.B. nicht so gut zu Test-Driven-Development, bei dem die Klassen sich erst bei der Implementierung ergeben.
• Die Artefakte müssen auch zeitlich sinnvoll im Projekt untergebracht werden. Die Anforderungen erst nach der Implementierung zu dokumentieren ist sinnfrei.
• Artefakte sollen im Prozess auch einen erkennbaren Mehrwert für die späteren Prozessschritte bieten. Mockups sind z.B. sehr hilfreich, um auf ihrer Basis ein Datenmodell zu erzeugen. Und auf Basis des Datenmodells können dann wiederum Klassen modelliert werden usw.
• Durch den passenden Einsatz der Artefakte in den jeweiligen Prozessschritten füllt sich die Projektdokumentation automatisch mit spannenden Inhalten für die Prüfer:innen!

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, Screenshots der Anwendung, Tabellenmodell, Screenshots der Projektstruktur
• Deployment auf Zielumgebung durchführen
  • mögliche Ergebnisse: Dockerfile, Screenshots Build-/Deployment-Pipeline, Ticketverlauf, Screenshots der finalen Umgebung

Qualitätssicherung

• Eigene Maßnahmen umsetzen (am besten schon während der Implementierung)
  • mögliche Ergebnisse: interessanter Code aus Unit-Tests/Integrationstests/Systemtests/Oberflächentests, Screenshots der Code Coverage oder statischen Codeanalyse
• Externe Unterstützung
  • mögliche Ergebnisse: Code-Reviews (was ist herausgekommen?), Pull-Requests, Code-Walkthroughs, Testprotokoll, Abnahmeprotokoll, Testsuite in Testtool

Dokumentation

• Langfristigen Betrieb der Lösung zielgruppengerecht dokumentieren
  • mögliche Ergebnisse: Kunden-/Benutzerdokumentation, Entwicklungsdokumentation, Administrationsdokumentation, Installationsanleitung, README, Verteilungsdiagramm, Wiki-Artikel, Build-Pipeline, Klassendiagramm, Tabellenmodell

Beispielablauf

Fiktives Beispiel: Es soll eine bestehende Excel-Lösung abgelöst werden durch eine Webanwendung.

• Ist-Analyse/Anforderungen: Gespräch mit bisherigen Anwender:innen, Ablauf als EPK dokumentieren, daran Schwachstellen (z.B. Medienbrüche) aufzeigen, Anforderungen währenddessen unstrukturiert als Notizen sammeln
  • Artefakte: EPK (alt), Screenshots der bisherigen Excel-Datei
• Anforderungen strukturieren: Notizen aufbereiten und um weitere Stakeholder (z.B. Entwickler:innen) ergänzen, einheitliche Formulierung als User Storys, Anwendungsfälle modellieren
  • Artefakte: Use-Case-Diagramm, Lastenheft (Liste der User Storys)
• Neue Lösung skizzieren: Prozess für Lösung des Problems als EPK modellieren (zum besseren Vergleich zur bisherigen Lösung)
  • Artefakt: EPK (neu)
• Plattform festlegen: Webanwendung, da am einfachsten zu deployen
• UI gestalten und mit Stakeholdern abstimmen, gerne low-level auf Papier oder dem iPad
  • Artefakt: Mockups
• Datenmodell aus den Mockups (und weiteren Anforderungen) ableiten
  • Artefakt: Entity-Relationship-Modell
• Architektur der Anwendung mit Domain Driven Design planen, Domäne ohne Abhängigkeiten und losgelöst von Infrastruktur
  • Artefakte: Komponentendiagramm, Glossar der zentralen Domänenbegriffe
• Datenhaltung definieren: MariaDB, weil schon etabliert im Unternehmen
• Programmiersprache und Frameworks auswählen: Java mit Quarkus, weil schon im Unternehmen etabliert und gut für Container geeignet
  • Artefakte: Liste der eingesetzten Technologien mit konkreten Versionsnummern
• Geschäftslogik und Domäne aus Datenmodell ableiten
  • Artefakte: grobes Klassendiagramm ohne Methoden zur Orientierung, Sequenzdiagramm für zentralen Algorithmus
• Build und Deployment modellieren: Build mit Gradle/Jenkins und Betrieb in Docker/Kubernetes
  • Artefakte: Deploymentdiagramm, Build-Pipeline (Code), Dockerfile (Code), Buildfile (Code)
• Qualitätssicherung planen: Implementierung mit TDD, technische Abnahme über Pull-Requests, statische Codeanalyse mit Sonarqube
• Obige Ergebnisse im im Pflichtenheft zusammenfassen
  • Artefakt: Pflichtenheft
• Implementierung Code-First durchführen mittels TDD orientiert am Datenmodell/Klassendiagramm/Komponentendiagramm mit Feature-Branches in Git
  • Artefakte: Code-Beispiele (Produktiv- und Testcode), Screenshots der Anwendung, Screenshot grünes Quality-Gate in Sonarqube, Screenshot Pull-Request, Kommentare aus dem Code-Review
• Deployment auf Zielumgebung durchführen mittels Pipeline in Jenkins
  • Artefakte: Screenshots der grünen Deployment-Pipeline
• Dokumentation für Anwender:innen und Entwickler:innen erstellen
  • Artefakte: Benutzerdokumentation, API-Dokumentation mit JavaDoc, README im Git-Repository, komplettes Klassendiagramm (generiert), Tabellenmodell (generiert)

Links

• Permalink zu dieser Podcast-Episode
• RSS-Feed des Podcasts
• Word-Vorlage für die Projektdokumentation der IT-Berufe

Weitere Infos zur Projektdokumentation

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

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

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

Jetzt anmelden!

Der Beitrag Sinnvoller Aufbau/Ablauf eines IHK-Projekts in der Anwendungsentwicklung – IT-Berufe-Podcast #185 erschien zuerst auf IT-Berufe-Podcast.

Um alles rund um Verträge als Vorbereitung auf die AP1 geht es in der einhundertvierundachzigsten Episode des IT-Berufe-Podcasts.

Inhalt

Für die AP1 ist es sinnvoll, einige grundsätzliche Vertragsarten zu kennen und unterscheiden zu können. Sowohl auf Anbieter- als auch auf Nachfragerseite ist es wichtig zu verstehen, welche Art von Vertrag vorliegt, da daraus unterschiedliche Rechte und Pflichten entstehen können.

Disclaimer: Das hier ist keine Rechtsberatung!

Vertrag

Ein Vertrag ist die von zwei (oder mehr) Vertragsparteien erklärte Einigung über die Begründung eines Schuldverhältnisses (siehe § 311 BGB). Hierfür sind zwei übereinstimmende Willenserklärungen erforderlich. Beispiel: Angebot und Annahme, Bestellung und Lieferung.

Verträge können schriftlich, mündlich oder durch „konkludentes Handeln“ entstehen.

Vertragsarten

• Kaufvertrag: Verkäufer:in verkauft etwas an Käufer:in.
  • Beispiele in der IT: Hardware-/Softwarekauf
• Lizenzvertrag: Lizenzgeber:in räumt Lizenznehmer:in Rechte an einem geschützten Werk (z.B. Patent, Marke, Urheberrecht) ein.
  • Beispiele in der IT: Lizenzierung von Software, Bildrechte einkaufen
• Servicevertrag: Regelt die Erbringung produktbezogener Leistungen zwischen Anbieter:in und Kund:in.
  • Beispiele in der IT: Wartungsverträge für Software (z.B. für Patches und Updates) oder Hardware durch Dienstleister
• Mietvertrag: Vermieter:in überlässt Mieter:in eine bewegliche oder unbewegliche Sache zur zeitweisen Nutzung.
  • Beispiele in der IT: Miete eines Autos für eine Dienstreise, Miete von Software
• Leasingvertrag: Leasinggeber:in (Vermieter:in) überlässt Leasingnehmer:in (Mieter:in) eine Sache zur Nutzung wie bei der Miete, aber mit Fokus auf eine langfristige Nutzung mit der Möglichkeit des Erwerbs am Ende der Vertragslaufzeit. Außerdem sind bestimmte Sachverhalte anders geregelt, z.B. die Inspektion beim geleasten Auto oder die Wahl des konkreten Modells und der Ausstattung durch den/die Leasingnehmer:in.
  • Beispiele in der IT: Leasing teurer Hardware statt einmaligen Kaufs
• Werkvertrag: Unternehmer:in (Auftragnehmer:in) verpflichtet sich zur Herstellung eines bestimmten Werks für den/die Auftraggeber:in (Besteller:in). Hier muss das Endergebnis klar definiert sein („Werk“).
  • Beispiele in der IT: Programmierung einer kompletten Individualsoftware für eine Kundin
• Dienstvertrag: Schuldner:in verpflichtet sich zur Leistung eines Dienstes an den/die Gläubiger:in. Hierbei steht die Dienstleistung an sich im Vordergrund und nicht das Endergebnis.
  • Beispiele in der IT: Programmierung für einen Kunden auf Basis von Tagessätzen
• Fernabsatzvertrag: Bei Verträgen, die über Fernkommunikationsmittel (Internet, Telefon usw.) geschlossen werden, haben Verbraucher:innen besondere Rechte, insb. ein Widerrufsrecht.
• Arbeitsvertrag: Definiert die Rechte und Pflichten von Arbeitgeber:in und Arbeitnehmer:in.

Vertragsbestandteile

z.B. Leistungsbeschreibung, Termine/Fristen, fällige Entgelte, Lasten- und Pflichtenheft (insb. bei Softwareerstellung), Konventionalstrafen, Haftung

Allgemeine Geschäftsbedingungen (AGB)

Mit AGBs regeln Unternehmen ihre grundsätzliche Vertragsgestaltung, also Inhalte, die für alle Verträge gelten.

Beispielinhalte:

• Informationen zum Vertragsschluss (z.B. Telefon, E-Mail), Bestätigungen usw.
• Zahlungsbedingungen (z.B. Fristen, Zahlungsmöglichkeiten)
• Eigentumsvorbehalt
• Lieferungskonditionen und -möglichkeiten
• übliche Geschäftszeiten
• Gewährleistung/Garantie
• Haftung

Service-Level-Agreement (SLA)

Ein SLA legt fest, wie Auftraggeber:in und Dienstleister:in bei wiederkehrenden Dienstleistungen zusammenarbeiten und welche individuellen Verantwortlichkeiten sie tragen.

Beispielinhalte:

• Leistungsbeschreibung: z.B. Hosting einer Website
• Verfügbarkeit des Services: z.B. Verfügbarkeit 99%, vereinbarte Wartungsfenster
• Erreichbarkeit des Dienstleisters: z.B. Geschäftszeiten, Reaktionszeit bei unterschiedlich schweren Problemen
• Preisgestaltung: z.B. 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)

Der Beitrag Verträge, AGBs, SLAs – IT-Berufe-Podcast #184 erschien zuerst auf IT-Berufe-Podcast.

Um Softwarequalität nach ISO 9126 geht es in der einhundertdreiundachzigsten Episode des IT-Berufe-Podcasts. Inhalt Definition von Qualität Qualität ist der Grad der Übereinstimmung mit den Anforderungen. Da verschiedene Stakeholder unterschiedliche Anforderungen an unser Projekt haben, ist die Qualität recht subjektiv. Alle Stakeholder zu 100% zufrieden zu stellen, wird in einem echten Projekt wohl nicht möglich...

Der Beitrag Softwarequalität nach ISO 9126 – IT-Berufe-Podcast #183 erschien zuerst auf IT-Berufe-Podcast.