IT-Berufe-Podcast

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

TL;DR

An Beispielen aus dem Alltag zeige ich dir, wie Datenbanktransaktionen zusammengehörige SQL-Statements als Einheit ausführen und welche Eigenschaften ACID dafür beschreibt. Du erfährst, wie Isolation parallele Zugriffe absichert, welche Fehler dabei auftreten können und wie du Transaktionen mit SQL oder einem ORM steuerst. Für verteilte Datenbanken kommen das CAP-Theorem und BASE hinzu, die beschreiben, welche Anforderungen an konsistente und verfügbare Daten bestehen. Als IT-Azubi brauchst du dieses Wissen beim Entwickeln von Anwendungen; ACID gehört außerdem zum Prüfungsstoff.

Kapitelmarken

[00:00:01] Thema und Bedeutung für die IT-Ausbildung

[00:02:58] Was ist eine Datenbanktransaktion?

[00:03:28] Beispiel Banküberweisung

[00:04:53] Der Begriff Transaktion im Datenbankkontext

[00:06:33] Beispiel Blogbeitrag und Tag

[00:08:17] Beispiel Bestellung und Bestellposition

[00:09:18] Beispiel Versicherungstarif

[00:11:28] Die ACID-Prinzipien

[00:12:52] Atomicity: Atomarität

[00:15:06] Consistency: Konsistenz

[00:16:35] Isolation bei parallelen Zugriffen

[00:18:58] Durability und Transaktionslogs

[00:22:48] Isolationsebenen und Sperren

[00:26:24] Serializable

[00:29:14] Repeatable Read

[00:30:19] Read Committed

[00:32:03] Read Uncommitted

[00:33:39] Fehler bei parallelen Transaktionen

[00:34:12] Dirty Reads

[00:36:37] Lost Updates

[00:38:20] Non-Repeatable Reads

[00:40:05] Phantom Reads

[00:42:17] Fehler den Isolationsebenen zuordnen

[00:44:36] Transaktionen in SQL und Autocommit

[00:46:58] BEGIN TRANSACTION, COMMIT und ROLLBACK

[00:48:26] Transaktionen mit ORMs

[00:52:13] Jakarta Transactions und Transaction Around

[00:56:24] Verteilte Datenbanken und Replikation

[01:02:19] Das CAP-Theorem

[01:03:32] Konsistenz bei ACID und CAP

[01:04:34] Die Eigenschaften von CAP

[01:07:17] Die BASE-Prinzipien

[01:09:19] Verfügbarkeit am Beispiel eines Streamingdienstes

[01:11:35] Basically Available

[01:12:15] Soft State

[01:12:53] Eventual Consistency

[01:15:14] Shownotes und Prüfungsrelevanz

[01:16:43] Newsletter zur IT-Ausbildung

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

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.

TL;DR

Für dein Abschlussprojekt als Fachinformatiker:in Anwendungsentwicklung empfehle ich eine betriebliche Aufgabe, bei der du selbstständig Software entwickelst und dein Vorgehen mit passenden Artefakten belegst. Eine kleine Anwendung mit Datenhaltung und einer Oberfläche bietet dafür zusammen mit eigener Geschäftslogik einen passenden Rahmen. Als grobe Orientierung reicht eine Handvoll Entitäten; entscheidend ist, dass du die vorgesehenen 80 Stunden sinnvoll ausfüllst. Wenn eine Komponente fehlt, müssen die übrigen Bereiche mehr fachliche Tiefe und methodische Nachweise liefern. Ein genehmigter Projektantrag gibt dir einen ersten Anhaltspunkt, während deine Note von dem abhängt, was du im Projekt zeigst.

Kapitelmarken

[00:00:00] Thema: Fachliche Tiefe des Abschlussprojekts

[00:02:22] Aussagekraft eines genehmigten Projektantrags

[00:05:33] Wie Prüfer:innen Projektanträge beurteilen

[00:08:32] Berufliche Handlungsfähigkeit und methodische Nachweise

[00:09:46] Datenhaltung, Geschäftslogik und Schnittstellen

[00:13:57] Daumenregeln für Umfang und eigene Algorithmik

[00:15:42] Fehlende Komponenten und aussagekräftige Artefakte

[00:20:42] Orientierung an Tabellen, Klassen und Bildschirmansichten

[00:21:51] REST-APIs ohne grafische Oberfläche dokumentieren

[00:24:30] Beispiele für passende Projektthemen

[00:25:39] Wann du ein anderes Projekt wählen solltest

[00:26:37] Beispiel: Eine digitale IT-Bibliothek

[00:28:15] Schwierigkeiten bei SAP-Projekten

[00:31:00] Zu kleine Projekte und realistische Zeitplanung

[00:32:14] Thema prüfen und Unterstützung im Ausbildungsbetrieb suchen

[00:33:55] Ergänzende Inhalte zur Methodik und Hilfe im Forum

[00:35:36] Website und Newsletter

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

Zusammenfassung

Was du mit deinem Abschlussprojekt zeigen sollst

Als Prüfer achte ich darauf, ob du eine betriebliche Aufgabe selbstständig von Anfang bis Ende bearbeiten kannst. Für dich als IT-Azubi im Beruf Fachinformatiker:in Anwendungsentwicklung gehört dazu, dein Projekt zu planen und die Kosten zu kontrollieren. Du berechnest auch, wann sich die Software amortisiert, während du die benötigten Ressourcen einplanst. Wie du Software methodisch entwickelst, belegst du durch passende Artefakte in deiner Projektdokumentation.

Was ein genehmigter Antrag aussagt

Der Prüfungsausschuss prüft anhand deines Antrags, ob sich dein Vorhaben als Abschlussprojekt eignet. Je nach IHK stehen dir dafür nur wenige Textfelder zur Verfügung, sodass Prüfer:innen Teile deines Vorhabens aus der Beschreibung ableiten müssen. Dabei entstehen Erwartungen an den Umfang und an die Artefakte, die du später zeigst.

Prüfer:innen arbeiten ehrenamtlich und bearbeiten teilweise viele Anträge innerhalb kurzer Fristen. Grundsätzlich sollen zwei Personen jeden Antrag prüfen....

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.

...