MarcoOderkerk.de

Diese Seite wird aktuell komplett überarbeitet

2026-06-07T15:32:15+02:00

Da das Wordpress 7 Update massive Probleme gemacht hat , baue ich diee Seite auf einem neuen technologiestack kompett neu auf. Es kann also zwischen durch zu Problemen kommen. Ob ich alle Infos von der alten Seite übernehme muss ich mir noch überlegen.

KI Marketing vs Realität

2026-06-07T12:16:45+02:00

Seit längere Zeit wird KI immer wichtiger in der Welt und besonders im Bereich der Softwareentwicklung. Doch meiner Meinung nach ist zwischen Marketingversprechen und der Realität stellenweise ein ziemlich tiefer Abhang.
Hier teile ich mal meine private Einschätzung.

Was KI heute tatsächlich gut kann

Routine-Code beschleunigen

KI spart viel Zeit bei:

CRUD-Code
DTOs
Mappings
Unit Tests
SQL-Abfragen
API-Clients
Dokumentation (Wer hat das nicht gehasst ?)
Refactorings
Schnellere Recherche bei Issues.
Wissen komprimieren

Ein erfahrener Entwickler kann dadurch oft 20–50 % schneller werden.

KI als Sparringspartner / Pairingpartner

Ein guter Einsatz ist:

"Bewerte meine Architektur."

"Welche Risiken hat dieser Ansatz?"

"Welche Alternativen gibt es?"

Das funktioniert häufig erstaunlich gut.

Was KI schlecht kann

Große Systeme verstehen

Marketing sagt:

"Die KI versteht deine gesamte Codebasis."

Realität zeigt:

Bei einigen tausend Dateien wird es schwierig.

Die KI kennt:

nicht alle historischen Entscheidungen
nicht alle Geschäftsregeln
nicht alle impliziten Abhängigkeiten

Genau dort entstehen viele Produktionsfehler.

Fachlichkeit

Ideenfindung und Konzeption

Marketing sagt:

„KI generiert komplette Konzepte in Minuten.“

„Produktideen entstehen automatisch.“

„KI ersetzt Workshops.“

In Wirklichkeit liefert KI Rohmaterial, aber kein tragfähiges Konzept und Fachbereiche müssen trotzdem priorisieren, validieren, entscheiden.
KI erzeugt oft zu viele Optionen, was Entscheidungen verlangsamt.
Effekt auf TTM : 10-20%

Domänenwissen:

"Was darf das System überhaupt tun?"

KI kennt die Domäne oft nur oberflächlich, wie soll die KI dann rechtssichere Antworten geben.
Beispiel : etwas was in einem Logistik-System vielleicht erlaubt ist, kann in einem Banken oder gar medizinischen System verboten sein.

Solange KI Modelle nicht vollen, isolierten Zugriff auf alle relevanten Informationen der Domäne haben und nur die Daten der Domäne für die Arbeit nutzen, ist jede Entscheidung detailiert zu reviewen und zu hinterfragen.

Marketing sagt:

„KI schreibt automatisch User Stories, Epics, Akzeptanzkriterien.“

„Keine Requirements Engineers mehr nötig.“

Realität : KI kann Stories generieren, aber oft unpräzise, nicht domain‑spezifisch, widersprüchlich, d.h. Teams müssen alles reviewen, korrigieren, priorisieren.
Aber bei guten Prompts und einer klaren Architektur ist die Auswirkung auf TTM 20%-40%

Softwareentwicklung

Marketing sagt:

„KI schreibt 80 % des Codes.“

„Entwickler werden zu Reviewern.“

„MVP in Wochen statt Monaten.“

In der Realität kann es klappen, aber bei größeren Systemen kann die KI zwar Code generieren., aber sehr oft ist der Code nicht buildfähing und es sind mehrere Durchgänge notwendig. Auch die Kompatibilität mit der bestehenden Architektur , gerade in gewachsenen Systemen ist sehr oft nicht gegeben. Auch die Sicherstellung , dass keine Sicherheitslücken eingebaut werden , ist nicht 100%ig gegeben. Aus eigener Erfahrung weiß ich , dass gerade bei der Nutzung von Dritt-Anbieter-Libraries nicht unbedingt von der KI die aktuellsten Versionen eingebaut werden, sondern die Version, die beim Anlernen des Modells aktuell waren. Um dieses Sicherzustellen, bräuchte die KI eigentlich Zugang zu aktuellen CVE Informationen und den Versionsinformartionen.

Und dann haben wir noch die Testqualität, die KI hat aktuell noch Probleme bei der Edge-Cases Berücksichtigung. Als Entwickler kenne ich den Einfallsreichtum der Anwender und auf welche Ideen diese kommen können. Eine KI hat hier Probleme.
Auch Testfehler in Unit Tests sind des öfters eine Herausforderung der KI. Die KI hat die Methode gebaut die getestet wird und es kommt ein falsches Ergebnis raus. Hat nun die Methode einen Fehler oder der Testfall. Hier verhält sich die KI ab und zu echt menschlich. Passt das Ergebnis nicht zum erwarteten , passe ich einfach das erwartete Ergebnis an , auch wenn das Ergebnis falsch ist. Der Test ist auf jeden fall grün.

Aus meiner Sicht verbringen Entwickler aufgrund dieser Punkte mehr Zeit mit Debugging, Refactoiring und Architektur-Alignment.

Der Effekt auf das TTM ist hier meiner Meinung nach nur max. 30% , bei machen Legacy-Systemen sogar eher negativ. Kleiner Änderungen sind kein Problem , aber bei neuen Features , bei dem das ganze System mit der bisherigen Architektur bekannt sein muss , sehe ich skeptisch entgegen, es sei denn man hat unlimited Token um das ganze System als Kontext mitgeben zu können.

Ich denke bei Neuentwicklungen siehts viel besser aus. Aber wann startet man mal auf der grünen Wiese.

Noch ein kleiner Zusatz zu den Tests.

Marketing sagt:

„KI generiert automatisch Unit‑Tests, Integrationstests, E2E‑Tests.“

„Qualität steigt automatisch.“

Wie schon oben gesagt , sieht die Realität teilweise anders aus. Jeder Test ist erstmal besser als kein Test. Aber ich habe festgestellt , das manchmal Tests redundant angelegt werden , nicht nach der ersten Generierung laufen bzw. wartbar sind.
Und je nach Anwendungsgebiet, müssen sinnvolle Testdaten noch manuell geliefert werden. Auch Mocks von externen Systemen müssen teilweise manuell bereitgestellt werden, da diese nicht im Kontext der KI stehen und die KI nur raten kann wir der Mock aussehen muss.
Daher würde ich sagen in Bezug auf Tests ist positive Auswirkung auf TTM bei max. 20%, wen es sich um moderne , modulare Codebasen handelt.

Deployment und Betrieb

Marketing sagt:

„KI automatisiert DevOps.“

„CI/CD wird selbstoptimierend.“

„Zero‑Ops.“

Das stimmt aus meiner Sicht teilweise. KI kann die entsprechenden Konfigurationen, pipelines , Dockerfiles ,... erstellen Aber schauen wir uns doch mal die Punkte Security‑Policies, Secrets, Compliance und Infrastruktur an. Aus wirtschaftlicher Sicht hatte ich echt probleme , wenn die KI eigenständig sich um ihre Hardware kümmen könnte und z.B frei VPS bestellen könnte. Oder das Thema Passwörter. Einer KI Passwörter anzuvertrauen , ohne zu Wissen , was mit den input Token bei den Toolherstellern wirklich passiert, würde mir massive Bauchschmerzen bereiten.
Aber bezüglich Zugangsdaten , wurde ja schon öfters in verschiedesten Quellen erzählt, das Zugangsdaten in Klartext im Sourcecode hinterlegt wurden. Ich selber hab das mal bei einem Testprojekt ausprobiert und die KI hat es auch gemacht. Auf die Frage , warum dieKI das gemacht hat , kam die Antwort , das könnte man später nochmal refactoren , aber erstmal geht es darum einen produktionsreifen MVP zu bekommen.

Daher meine Bewertung bzgl. dem Effekt auf TTM : 5-20 %.

Verantwortung

Wenn ein Fehler in Produktion geht:

Der Entwickler "haftet" beruflich dafür.
Nicht die KI.

Deshalb bleibt Review unverzichtbar.
Aber der durch das Marketing angedeutete Geschwindigkeitsgewinn kann hier zum Gegenspieler werden.
KI entwickelt Code , Entwickler muss die Lösungsstrategie der KI erkennen und verstehen, den Code analysieren, Tests auf sinnhaftigkeit prüfen und so weiter.

Die Aussage ,,KI hat das programmiert'' zieht leider nicht.
Da das Marketing sagt , dass Software Entwickler zu Reviewern werden, kann ich nicht unterstützen. Ich würde eher sagen dass Entwickler zu KI Lotsen werden , sie steuern die K, ähnlich ie Fluglotsen die Flugzeuge. Und da ein Fluglotze max. 4 Stunden am Stück das machen dürfen, damit keine Fehler geschehen, überlegt mal was bei Entwicklern nach 8h KI Steuerung und Output reviews passieren kann.
Ich habe mal 2 Modelle gefragt und beide Modelle haben mir gesagt, dass bis zu 30% bis 40% mehr Fehler in Produktion landen könnten.

Wer profitiert nun von der KI Nutzung am meisten?

Wer glaubt, dass es Anfänger sind, der wird enttäuscht sein. Anfänger sind es nicht , da sie oft falsche Antworten, Sicherheitsprobleme und ungünstige Architekturen nicht erkennen. Und ob Anfänger etwas lernen und Berufserfahrung sammeln, wenn sie nur auf "Keep All" klicken, bezweifel ich. Es gibt natürlich auch hier Ausnahmen wie wirkliuch verstehen wollen , was das gebaut wird , aber bei vielen Vibe-Codern ist das nicht der Fall.

Senior Entwickler können allerdings von der KI profitieren. Sie erkennen sofort, was gut , was Unsinn ist und was fehlt. KI kann hier wirklich zum Pairingpartner werden.

Welche Jobs werden verschwinden?

Marketing sagte in der Vergangenheit immer , durch KI können viele Arbeitsplätze entfallen und massive Einsparungen durchgeführt werden. (Zum Thema Kostenentwicklung werde ich noch einmal einen weiteren Beitrag schreiben)

Ich sehe das etwas anders :

Gefährdet

Reine "Code-Monkey"-Aufgaben:

Standard-CRUD
einfache Webseiten
Boilerplate
einfache APIs

Weniger gefährdet

Aufgaben mit viel:

Architektur
Kommunikation
Fachlichkeit
Verantwortung
Systemdesign

Denn wir müssen im Kopf behalten:

Unternehmen bezahlen selten für Codezeilen, sonderndafür, dass ein Problem korrekt gelöst wurde.

Viele Entwickler glauben:

"KI schreibt meinen Job weg."

Ich sehe eher:

Entwickler, die KI gut nutzen, ersetzen Entwickler, die KI ignorieren.

Ähnlich wie früher:

Git ersetzte keine Entwickler.
IDEs ersetzten keine Entwickler.
Stack Overflow ersetzte keine Entwickler.

Aber die Produktivitätserwartungen stiegen und stiegen.

Was sich in den nächsten 5 Jahren wahrscheinlich ändern wird

Der Alltag verschiebt sich von:

80 % Code schreiben
20 % Denken

zu eher:

30 % Code schreiben
70 % Prüfen, Entwerfen, Entscheiden

Das eigentliche Engpass-Thema wird weniger die Syntax von Java oder Spring, oder was auch immer sein, sondern mehr:

Anforderungen verstehen
Systeme entwerfen
Risiken erkennen
KI-Ergebnisse validieren

Mein Fazit

Für einen Java-Entwickler im Jahr 2026ff ist KI kein Ersatz für Fachwissen, sondern ein Verstärker. Wer nur Framework-Methoden auswendig kennt, bekommt wahrscheinlich Probleme.

Wer dagegen versteht:

Architektur
Datenmodellierung
Verteilte Systeme
Performance
Security
Fachdomänen

wird mit KI oft produktiver als je zuvor.

Die größte Gefahr ist nicht, dass KI alle Entwickler ersetzt. Die größere Gefahr ist, dass man ihre Stärken und Schwächen falsch einschätzt: Manche erwarten Magie, andere ignorieren sie komplett. Beide Extreme führen meist zu schlechten Entscheidungen.

Mir tun nur die Junior-Entwickler leid.Wenn wir uns mal ansehn, was Junior Entwicker früher gemacht haben:

einfache CRUD-Services
kleine Bugfixes
Boilerplate-Code
einfache UI/API-Endpunkte

Genau diese Sachen kann KI heute ziemlich gut → dadurch gibt es weniger reine Low-Complexity Tasks.

Man beginnt klein und arbeitet sich hoch. Und das kleine verschwindet zum größten Teil.

Einstiegshürde ist höher geworden

Viele Teams erwarten inzwischen von Juniors:

Git sicher beherrschen
grundlegende Architektur verstehen
Tests schreiben können
nicht nur Code kopieren, sondern verstehen
KI-Tools sinnvoll nutzen (z. B. ChatGPT/Copilot)

Das wirkt wie “schwieriger Einstieg”, ist aber eher eine Erwartungsverschiebung.

Ein Junior war früher oft:

“Ich lerne Programmieren im Job”

Heute eher:

“Ich kann schon programmieren und lerne Systementwicklung im Job”

Das ist der Unterschied.

Paradox, aber wichtig:

Einstieg ist schwerer
aber Lernkurve ist schneller

Mit KI kann ein guter Junior heute:

schneller produktiv werden
schneller verstehen, wie Systeme gebaut werden
früher komplexere Aufgaben übernehmen

IT Shorts : Threadmodelling

2026-06-06T13:17:00+02:00

In der IT-Sicherheit bezieht sich Threadmodelling auf einen Prozess, bei dem potenzielle Bedrohungen und Angriffsvektoren identifiziert werden, um Sicherheitslücken zu erkennen und Gegenmaßnahmen zu entwickeln. Es hilft dabei, Schwachstellen im System zu verstehen und angemessene Sicherheitsvorkehrungen zu treffen.

Ein Beispiel für Threadmodelling in der IT-Sicherheit könnte sich auf die Entwicklung einer E-Commerce-Website beziehen:

Identifizierung der Bedrohungen:

Unbefugter Zugriff auf Benutzerdaten
Injection-Angriffe (z.B. SQL-Injection)
Cross-Site Scripting (XSS)
Denial-of-Service-Angriffe (DoS)
Brute-Force-Angriffe auf Benutzerkonten

Analyse der potenziellen Auswirkungen:

Diebstahl von Benutzerdaten (z.B. Kreditkarteninformationen)
Manipulation von Datenbankinhalten
Kompromittierung von Benutzerkonten
Beeinträchtigung der Verfügbarkeit der Website

Bewertung der bestehenden Sicherheitsmaßnahmen:

Verwendung von sicheren Verschlüsselungsprotokollen (z.B. HTTPS)
Implementierung von Input-Validierung und Datenbereinigung
Einsatz von Web Application Firewalls (WAF)
Überwachung und Erkennung von Anomalien im Datenverkehr

Entwicklung von Gegenmaßnahmen:

Umsetzung von Zugriffskontrollen und Authentifizierung
Implementierung von Sicherheitspatches und regelmäßige Updates
Schulung der Entwickler in sicherer Codierung und sicheren Entwicklungsmethoden
Durchführung von Penetrationstests und Sicherheitsaudits

Durch das Threadmodelling in der IT-Sicherheit können potenzielle Bedrohungen und Schwachstellen erkannt werden, um angemessene Schutzmaßnahmen zu implementieren und die Sicherheit des Systems zu verbessern.

OPSEC: Der Schlüssel zu Sicherheit in der digitalen Welt

2026-06-06T13:05:40+02:00

In einer zunehmend vernetzten Welt, in der fast jeder Schritt von uns online nachvollziehbar ist, wird der Schutz der eigenen Informationen immer wichtiger. Der Begriff OPSEC (Operational Security) beschreibt eine Reihe von Maßnahmen, die darauf abzielen, sensible Informationen vor unbefugtem Zugriff zu schützen. Ursprünglich aus dem militärischen Bereich stammend, hat OPSEC heute auch in der zivilen Nutzung eine große Bedeutung erlangt, insbesondere in Bezug auf Datenschutz, Cybersicherheit und die allgemeine Vorsicht im Umgang mit persönlichen Daten.

Was ist OPSEC?

OPSEC steht für „Operational Security“, was übersetzt so viel wie „Betriebs- oder Einsatzsicherheit“ bedeutet. Es handelt sich um eine Strategie, die darauf abzielt, die Schwächen und Bedrohungen eines Systems zu erkennen und zu minimieren, um zu verhindern, dass sensible Informationen in die falschen Hände geraten. Der Fokus liegt dabei auf der Identifikation und Reduzierung von „Kritischen Informationen“, die von einem Angreifer genutzt werden könnten.

Im Wesentlichen geht es bei OPSEC darum, durch vorausschauende Maßnahmen die Wahrscheinlichkeit zu minimieren, dass jemand Informationen über deine Aktivitäten, dein Verhalten oder deine Ressourcen erlangt, die dann gegen dich verwendet werden können.

Warum ist OPSEC wichtig?

In der heutigen digitalen Welt, in der nahezu jede Handlung in irgendeiner Form erfasst wird, sind Informationen eine wertvolle Ressource – sowohl für Angreifer als auch für Unternehmen, Regierungen und Organisationen. Persönliche Daten, Passwörter, Kontoinformationen und sogar scheinbar harmlose Details über den eigenen Alltag können von Cyberkriminellen ausgenutzt werden, um Identitätsdiebstahl zu begehen oder finanzielle Schäden zu verursachen.

Darüber hinaus wird OPSEC nicht nur von Hackern oder Cyberkriminellen in Angriff genommen. Auch Staaten, Unternehmen oder andere Organisationen sammeln Daten, um das Verhalten von Individuen zu analysieren oder sogar um gezielte Werbung und Manipulation zu betreiben. Deshalb geht es bei OPSEC nicht nur um den Schutz vor „bösen Akteuren“, sondern auch um den Schutz der eigenen Privatsphäre und Kontrolle über persönliche Daten.

Die fünf Schritte des OPSEC-Prozesses

Der OPSEC-Prozess besteht aus fünf grundlegenden Schritten, die dabei helfen, sicherzustellen, dass keine sensiblen Informationen ungewollt preisgegeben werden:

Identifikation kritischer Informationen
Zunächst gilt es, herauszufinden, welche Informationen für den eigenen Betrieb oder die eigene Person besonders schützenswert sind. Dabei können es sich nicht nur um personenbezogene Daten handeln, sondern auch um Geschäftsgeheimnisse, IP-Adressen, Pläne für Projekte oder persönliche Vorlieben und Aktivitäten.
Analyse von Bedrohungen
Wer könnte an diesen Informationen interessiert sein? Hier gilt es, potenzielle Bedrohungen zu erkennen. Cyberkriminelle, Konkurrenten, staatliche Akteure, aber auch unachtsame Dritte könnten an den kritischen Informationen interessiert sein und versuchen, auf sie zuzugreifen.
Schwächen identifizieren
Wo liegen die Schwächen, die Angreifer ausnutzen könnten? Dies können offene Netzwerke, unverschlüsselte Datenübertragungen oder ungesicherte Geräte sein. Auch menschliche Fehler, wie das Weitergeben von Informationen in sozialen Netzwerken oder das Verwenden von unsicheren Passwörtern, stellen häufige Schwachstellen dar.
Maßnahmen zur Risikominderung festlegen
Sobald die Schwächen erkannt wurden, ist es wichtig, entsprechende Maßnahmen zu ergreifen, um diese zu beheben. Dazu gehören technische Lösungen wie die Verwendung von Verschlüsselung, Firewalls und sicheren Passwörtern sowie praktische Maßnahmen wie das Minimieren der Weitergabe von Informationen in sozialen Netzwerken oder die Schulung von Mitarbeitern im sicheren Umgang mit Daten.
Überwachung und Anpassung
OPSEC ist ein fortlaufender Prozess. Neue Bedrohungen entstehen ständig, daher müssen Schutzmaßnahmen regelmäßig überprüft und angepasst werden. Eine kontinuierliche Überwachung der eigenen Informationssicherheit hilft dabei, frühzeitig auf neue Risiken zu reagieren.

OPSEC im Alltag: Praktische Tipps

OPSEC muss nicht nur in der Arbeitswelt, sondern auch im privaten Bereich beachtet werden. Hier sind einige einfache, aber effektive Tipps, um die eigene Sicherheit zu erhöhen:

Verschlüssele deine Kommunikation: Nutze Ende-zu-Ende-verschlüsselte Nachrichten-Apps wie Signal oder WhatsApp, um sicherzustellen, dass nur der beabsichtigte Empfänger deine Nachrichten lesen kann.
Starke Passwörter und Zwei-Faktor-Authentifizierung (2FA): Verwende für jeden Account ein einzigartiges, starkes Passwort und aktiviere, wo möglich, die Zwei-Faktor-Authentifizierung. Dies erhöht die Sicherheit erheblich.
Vermeide das Teilen sensibler Informationen: Sei vorsichtig, was du in sozialen Netzwerken teilst. Manchmal reicht es aus, nur wenige Informationen preiszugeben, um ein vollständiges Profil einer Person zu erstellen.
Sei vorsichtig mit öffentlichen WLANs: Vermeide es, in öffentlichen Netzwerken sensible Transaktionen wie Online-Banking oder das Eingeben von Passwörtern durchzuführen. Falls nötig, nutze ein VPN (Virtual Private Network).
Schütze deine Geräte: Verwende Passcodes oder biometrische Sperren (Fingerabdruck, Gesichtserkennung) für deine mobilen Geräte und sichere deine Daten regelmäßig.

OPSEC und Datenschutz: Eine unerlässliche Kombination

OPSEC und Datenschutz sind eng miteinander verknüpft. Während OPSEC darauf abzielt, zu verhindern, dass kritische Informationen in die falschen Hände geraten, schützt Datenschutz die Rechte des Individuums in Bezug auf seine persönlichen Daten. Es geht dabei nicht nur um die technische Sicherheit von Informationen, sondern auch um die Wahrung der Privatsphäre und die Kontrolle über die eigenen Daten.

In vielen Ländern gibt es mittlerweile Gesetze und Vorschriften (wie die Datenschutz-Grundverordnung der EU), die den Umgang mit personenbezogenen Daten regeln. Unternehmen und Einzelpersonen müssen sich dieser Verantwortung bewusst sein, um den rechtlichen Anforderungen gerecht zu werden und ihre Daten entsprechend zu schützen.

Fazit: OPSEC als unverzichtbares Sicherheitskonzept

In der digitalen Ära ist OPSEC nicht nur für Militärs oder Unternehmen von Bedeutung, sondern auch für jeden einzelnen von uns. Es geht darum, sich der Risiken bewusst zu werden, die in der heutigen vernetzten Welt lauern, und gezielte Maßnahmen zu ergreifen, um die eigenen Informationen zu schützen. Indem wir bewusster mit unseren Daten umgehen, sichere Kommunikationskanäle nutzen und uns regelmäßig über aktuelle Bedrohungen informieren, können wir unsere digitale Sicherheit erheblich erhöhen und die Gefahren von Cyberkriminalität und Datenmissbrauch minimieren.

Letztendlich gilt: Sicherheit ist kein einmaliges Ziel, sondern ein fortwährender Prozess. Und OPSEC ist ein wichtiger Bestandteil dieses Prozesses.

IPv4 im Mobilfunk

2026-06-06T13:02:23+02:00

Im Mobilfunknetz erfolgt die Vergabe von IPv4-Adressen dynamisch und läuft in der Regel über ein Verfahren namens DHCP (Dynamic Host Configuration Protocol). Hier ist der Prozess im Detail erklärt:

1. Verbindung zum Mobilfunknetz

Wenn sich ein mobiles Endgerät (Smartphone, Tablet oder anderes Gerät) mit dem Mobilfunknetz verbindet, wird eine Verbindung zur Basisstation (Funkzelle) hergestellt. Diese Basisstation ist Teil des Zugangsnetzes des Mobilfunkanbieters und stellt die erste Instanz für die Netzwerkkonfiguration des Geräts dar.

2. Anfrage für IP-Adresse über das Kernnetz

Nachdem das mobile Endgerät im Zugangsnetz registriert ist, stellt es eine Anfrage an das Kernnetzwerk des Mobilfunkanbieters, um eine IP-Adresse zu erhalten. In modernen Netzwerken erfolgt dies in der Regel automatisch und nahtlos, ohne dass der Nutzer eingreifen muss. Hier kommt DHCP zum Einsatz.

Das mobile Gerät sendet eine DHCP-Anfrage (Discovery), um eine IP-Adresse zu erhalten.
Der DHCP-Server des Mobilfunknetzbetreibers erhält diese Anfrage und weist dem Gerät eine IPv4-Adresse zu. Diese IP-Adresse stammt in der Regel aus einem Pool dynamischer IP-Adressen, die für die Kunden des Netzwerks reserviert sind.

3. NAT (Network Address Translation) im Mobilfunknetz

Aufgrund der begrenzten Anzahl an verfügbaren IPv4-Adressen weltweit verwenden Mobilfunkanbieter in der Regel eine Technik namens NAT (Network Address Translation). Dabei erhält das mobile Endgerät eine private IPv4-Adresse, die nur innerhalb des Netzwerks des Mobilfunkanbieters gültig ist.

Private IP-Adresse: Innerhalb des Mobilfunknetzes werden Adressen aus den für private Netzwerke reservierten Bereichen (wie z.B. 10.0.0.0/8 oder 192.168.0.0/16) genutzt.
Öffentliche IP-Adresse: Wenn das Gerät auf das Internet zugreifen möchte, wandelt der NAT-Router des Netzbetreibers die private IP-Adresse in eine öffentliche IPv4-Adresse um, damit der Datenverkehr über das Internet weitergeleitet werden kann.

4. Carrier-Grade NAT (CGNAT)

Da die Anzahl der öffentlichen IPv4-Adressen begrenzt ist, verwenden viele Mobilfunkbetreiber Carrier-Grade NAT (CGNAT). Dies bedeutet, dass mehrere mobile Geräte im selben Netzwerk dieselbe öffentliche IPv4-Adresse teilen und die Unterscheidung über unterschiedliche Portnummern erfolgt. CGNAT stellt sicher, dass die knappen IPv4-Adressen effizient verwendet werden können, indem viele Geräte eine einzige öffentliche IP-Adresse nutzen.

5. Lease-Zeiten und dynamische Vergabe

Die zugewiesene IPv4-Adresse hat eine sogenannte Lease-Zeit, also einen Zeitraum, in dem das Gerät diese IP-Adresse verwenden kann. Nach Ablauf dieser Zeit muss die IP-Adresse entweder erneuert oder eine neue Adresse angefordert werden. Dieser dynamische Prozess sorgt dafür, dass IP-Adressen effizient wiederverwendet werden und keine Adressen dauerhaft belegt werden, wenn sie nicht aktiv genutzt werden.

6. IPv6 als langfristige Lösung

Da die Verfügbarkeit von IPv4-Adressen immer knapper wird, setzen immer mehr Mobilfunkanbieter auf IPv6. IPv6 bietet einen praktisch unerschöpflichen Adressraum und löst viele der Probleme, die mit der dynamischen Zuweisung und NAT-Techniken bei IPv4 einhergehen.

Zusammengefasst: Im Mobilfunknetz wird die IPv4-Adresse in der Regel dynamisch durch einen DHCP-Server zugewiesen, häufig über NAT oder CGNAT, um die begrenzten öffentlichen IPv4-Adressen effizient zu nutzen.

Systemkontext kurz erklärt

2026-06-05T22:52:33+02:00

Der Systemkontext beschreibt den Scope einer Entwicklung im Zusammenspiel mit anderen Systemen in einer Anwendungslandschaft.

Warum ist es nun wichtig , den Systemkontext so früh wie möglich festzulegen ?

Ganz einfach, man will sein System (weiter-)entwickeln und sich nicht um Fremdsysteme bei der Entwicklung und dem Design kümmern müssen. Daher sollte man früh festlegen , welche Komponenten und Systembestandteile zum eigenen System gehören und welche als Blackbox betrachtet werden können. Man legt also die Systemgrenzen fest.

Wie legt man den Systemkontext fest?

Im Zuge einer Systemkontextanalyse ermittelt man unter anderem die folgenden Punkte:

Stakeholder, Infrastrukturadministratoren
alle benötigten Prozesse
benötigte Schnittstellen

Zusätzlich zu diesen Punkten ist man ggf. gezwungen Gesetztesgrundlagen und Normen zu beachten. Diese sollten ebenfalls in den Systemkontext einbezogen werden.

Und wie immer : Es stehen zum Zeitpunkt der Analyse nicht alle Informationen und Entscheidungen zur Verfügung. Daher kann es durchaus vorkommen , dass man die Analyse und den Kontext im Projektverlauf wiederholen und anpassen muss.

Darstellungsform

Als Darstellungsform kann man die im UML2.0 enthaltene Anwendungsfalldiagramme oder ein Kompositionsstrukturdiagramme
genutzt werden.

Scrum eine kurze Einführung

2026-06-05T22:11:03+02:00

Definition

Bei Scrum handelt es sich um ein Vorgehensmodell/Framework des Agilen Projektmanagements. In den 1990er hat sich das Vorgehensmodell von einem rein auf Softwareentwicklung fokussierenden Modell zu einer allgemein gültigen Projektmanagment-Methode entwickelt.

Rollen in Scrum

In Scrum gibt es nur 3 Rollen:

Rolle	Beschreibung
Product Owner	Verantwortlich für die Eigenschaften und die Wirtschaftlichkeit eines Produktes. Definition und Priorisierung der zu entwickelnden Eigenschaften. Im Gegensatz zu anderen Projektmanagementmethoden ist der PO immer eine Einzelperson.
Entwickler- team	Verantwortet die Lieferung der Produkteigenschaftengemäß der Vorgaben des PO
Scrum Master	Überwachung das Scrum funktioniert. Moderation von Meetings und Verantwortlich für die Abschirmung des Entwicklerteams vor Störungen von außen.

Artefakte in Scrum

Im Gegensatz zu anderen Projektmanagement Methoden fokussiert sich Scrum auf 3 Artefakte

Artefakt	Beschreibung
Product Backlog	Beim Product Backlog handelt es sich um eine Sammlung von Requirements für zukünftige Sprints. Der PO priorisiert dieses und ist alleinig verantwortlich. Anforderungen sollten in Userstories fachlich beschrieben werden. Die Eigenschaften jeder Userstory sollte dem Akronym INVEST folgen : Independent – unabhängig. Sie sollte nach Möglichkeit nicht von anderen User Stories abhängen. Negotiable – verhandelbar. So lange das Produkt nicht ausgeliefert ist, können Änderungen vorgenommen werden. Valuable – nützlich. Ihre Umsetzung erhöht den Gebrauchswert des Produkts für den Endkunden. Estimable – quantifizierbar. Der Aufwand für die Umsetzung muss abschätzbar sein. Small – klein. Der Aufwand für die Umsetzung sollte überschaubar sein. Erstrebenswert sind einige Arbeitstage, maximal einige Wochen. Testable – überprüfbar. Ihre erfolgreiche Umsetzung sollte sich mit objektiven Kriterien überprüfen lassen.
Sprint Backlog	Beinhaltet alle Anforderungen die innerhalb des Sprints umgesetzt werden sollen.
Product Implemet	Funktionsfähige Produktversion , die nach dem Sprint zur Verfügung steht. Hierbei muss es sich nicht um die finale Version handeln.

Regelmäßige Aktivitäten / Events

Wie in jeder Projektmanagement Methode gibt es fixe Veranstaltungen.

Aktivtät/Event	Beschreibung
Spring Planung	Workshop in dem die Anforderungen für den nächsten Spring in Tasks mit einer Laufzeit von ~ 1 Tag zerlegt und eingeplant werden.
Daily	Täglicher Informationsaustausch des Entwicklungsteams. Max. 15 min Dauer. Falls Themen oder Probleme nicht im 15 min Zeitfenster behandelt werden können, werden diese an den Scrum Master übergeben.
Review	Nach jedem Spring werden die Ergebnisse geprüft und ggf das Backlog angepasst. Außerdem werden Rückmeldungen vom PO und den Stakeholdern eingeholt.
Retrospective	Überprüfung der Arbeitsweise für kontinuierliche Verbesserung .
Product Backlog Refinement	Der PO und das Entwicklerteam gehen das Product Backlog gemeinsam durch. Aktivitäten wird das Product Backlog geordnet, unwichtiges entfernt, neue Einträge aufgenommen, Anforderungen detailliert , geschätzt und Releases geplant.

Python3 – Teil 5 Dictonaries (Key Values)

2026-06-05T21:47:03+02:00

In diesem Beitrag schauen wir uns kurz Dictonaries an. Mit Hilfe von Dictionaries können wir Key Values / Mappings speichern. Kurz gesagt besteht ein Dictionary aus einem Key (assoziatives Feld) und seinem Value.
Schauen wir uns das ganze mal an einem Beispiel an.
Wir haben eine Anzahl von Tieren und deren lateinischen Namen in einem Dictionary.

tiere = {'Hund':'Canis','Katze':'feles','Maus':'Mus'}

print(tiere['Hund'])

Führen wir das Beispiel aus, erhalten wir den Wert „Canis“ als Ausgabe.

Das hinzufügen von Einträgen zu einem Dictionary ist ebenfalls möglich. Hier ein Beispiel :

tiere = {'Hund':'Canis','Katze':'feles','Maus':'Mus'}
tiere['Schwein'] = 'sus'
print(tiere)

Als Ausgabe erhalten wir nun

{'Hund': 'Canis', 'Katze': 'feles', 'Maus': 'Mus', 'Schwein': 'sus'}

Zusammengefasst []= .
Um Werte zu updaten kann man ebenfalls diese Syntax nutzen, indem wir einen bestehenden Key nutzen.
Wichtig an dieser Stelle noch zu sagen, ist dass das Value keine Liste sein kann. Die Verwendung von Tuples ist allerdings erlaubt.

Zum Löschen von Einträgen kann man die Dictionary-Methode pop() nutzen.

tiere.pop('Katze')

und schon ist die Katze Geschichte.

Möchte man 2 Dictionaries zusammenfügen , kann man dieses über die update() Methode machen. Sind in beiden Dictionaries identische Keys vorhanden , so werden die Werte des ersten Dictionaries beim Merge überschrieben.

tiere = {'Hund':'Canis','Katze':'feles','Maus':'Mus'}
tiere2 = {'Schwein':'sus' }
tiere.update(tiere2)
print(tiere)

Möchte man nu alle Einträge eines Dictionaries durchgehen , kann man dieses mittels einer For Schleife auf die Rückgabe der Dictionarymethode items() machen:

tiere = {'Hund':'Canis','Katze':'feles','Maus':'Mus'}
for deutsch, latein in tiere.items():
print('Der lateinische Name für ' + deutsch + ' ist ' + latein)
Der lateinische Name für Hund ist Canis
Der lateinische Name für Katze ist feles
Der lateinische Name für Maus ist Mus

Als Varianten hierzu kann man mittels der Dictionarymehtoden keys() alle Keys und über die Methode values() alle Values durchgehen.

Python3 – Teil 4 If else elif

2026-06-05T21:44:39+02:00

Wie in jeder anderen Programmiersprachen werden if Anweisungen zum Test von Bedingungen und der Reaktion auf das Prüfungsergebnis genutzt.
Auch in Python werden die arithmetischen Vergleichsoperatoren unterstützt :

Beschreibung	Operator
Gleichheit	==
kleiner als	<
kleiner oder gleich als	<=
größer	>
größer oder gleich als	>=
Ungleichheit	!=

Vergleichsoperatoren

Neben diesen Standardoperatoren gibt es zum „Suchen“ in Listen noch den „in“ und zur Prüfung, ob ein Eintrag nicht in einer Liste ist „not in“ Operator.

Hier ein paar Beispiele

Einfaches If :
Wenn das Alter kleiner gleich 17 ist , dann gibt eine Meldung aus.

if alter <=17:
print('Du kommst hier nicht rein')

Einfaches If Else Beispiel :
Wenn Alter < 18 , dann Lieblinksgetränk ist Milch, ansonsten Whisky.

if alter < 18:
lieblingsgetraenk = 'Milch'
else:
lieblingsgetraenk = 'Whisky'

Natürlich gibt es kompliziertere Beispiele :
Wenn Alter < 16 , dann Lieblinksgetränk ist Milch. Wenn Alter >=16 aber < 18 dann Bier ansonsten Whisky. Also eine klassische If ElseIf Else abfrage. Da Wir in Python aber auf gut lesbaren Code stehen , heißt bei uns das ElseIf nicht ElseIf sondern ElIf.

if alter >= 18:
lieblingsgetraenk = 'Whisky'
elif alter >= 16:
lieblingsgetraenk = 'Bier'
else:
lieblingsgetraenk = 'Milch'

Wie Ihr sicherlich schon gemerkt habt, sind in Python die Blöcke mit der Logik nicht wie in anderen Sprachen durch geschweifte Klammern gekapselt , sondern durch Einrückungen.

Dabei ist es egal , wie viele Anweisungen ausgeführt werden sollen :

if alter < 18:
lieblingsgetraenk = 'Milch'
lieblingsfarbe = 'blau'
else:
lieblingsgetraenk = 'Whisky'
lieblingsfarbe = 'rot'

Auf der einen Seite erleichtert diese Schreibweise die Lesbarkeit , ist aber auch eine leichte Fehlerquelle, da bereits eine Verschiebung um ein Zeichen , dem Interpreter Probleme bereitet.

Zu guter Letzt noch ein ein Beispiel für die Abfrage in Listen :

x = ['Hund','Katze','Maus']
if 'Katze' in x:
print('Mensch , das gibt Ärger')

Toronto 2008

2026-05-30T10:20:01+02:00

Hier war hauptsächlich Relaxen angesagt.Aber etwas Sightseeing musste natürlich auch sein.

Als erstes hab ich wie in Montreal eine Amphibienbus Tour gemacht (hier fährt man mit “Hippos” ) Kartenmarkierung C und am nächsten Tag eine Stadtrundfahrt im Doppeldeckerbus mit Hafenrundfahrt. Den Rest des Tages hab ich auf den Erholungsinseln vor Toronto verbracht. Hier stehen Schilder “ Bitte den Rasen betreten” , da kann sich so mache Stadt mal eine Scheibe von abschneiden.Dann war ich noch im Zoo von Toronto, CN Tower und im Rogercenter in dem nicht nur Eishockeyspiele stattfinden. Und natürlich auf Yonge Street shoppen.