---
author: B. A. Sylla
category: Howto
date: 2025-09-01
language: de
tags: Software Engineering
---

Howto - Leiter-Modell
=====================

<!--<img class="bloghead" src="../../../_static/img/blogimg/library_with_tables.jpg">-->

<small class="extrameta">Geändert: {sub-ref}`today`, Wörter: {sub-ref}`wordcount-words`, Lesedauer: {sub-ref}`wordcount-minutes` min</small>

Seit dem Boom der Online-Sprachmodelle im Jahr 2023 wie ChatGPT bin auch ich drauf angesprungen diese Technologie (transformer-basierte Modelltypen wie [BERT](https://en.wikipedia.org/wiki/BERT_(language_model)), [LLaMA](https://en.wikipedia.org/wiki/Llama_(language_model)), [GPT](https://en.wikipedia.org/wiki/Generative_pre-trained_transformer)) in alle möglichen Richtungen auszuprobieren. Zudem habe ich hunderte lokale Modelle wie [gemma-3-27b-it@q8_0](https://huggingface.co/lmstudio-community/gemma-3-27b-it-GGUF), [gpt-oss-120b@mxfp4](https://huggingface.co/lmstudio-community/gpt-oss-120b-GGUF), [phi-4@q8_0](https://huggingface.co/lmstudio-community/phi-4-GGUF) oder [qwen3-30b-a3b-thinking-2507@q8_0](https://huggingface.co/lmstudio-community/Qwen3-30B-A3B-Thinking-2507-GGUF) von Hand in [LM-Studio](https://lmstudio.ai/) getestet und genutzt oder mit [llama.cpp](https://github.com/ggml-org/llama.cpp) in der Linux-Shell gebencht.

Da ich bis 2023 dutzende Prototypen für Programmier-Bibliotheken entwickelt habe, habe ich mich nach ca. zwei Jahren (2025) auch immer mehr gefragt wie man ohne automatisiert [Vibe Coding](https://en.wikipedia.org/wiki/Vibe_coding) zu betreiben mit Chat-Sessions eine Art [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming) machen könnte. Beim Erlernen und Verfeinern meiner Skills in [Prompt Engineering](https://en.wikipedia.org/wiki/Prompt_engineering) ist mir aufgefallen, dass man Sprachmodelle am Bestem für das Feedback, für Rückfragen und für Vorschläge nutzen kann. Das geht praktisch in allen Phasen des [Wasserfall-Modells](https://de.wikipedia.org/wiki/Wasserfallmodell). Es begab sich also zu der Zeit, dass ich jenes Wasserfall-Modell modernisierte und in das Leiter-Modell umtaufte. Und es begab sich so.

## Ein Beispiel mit dem V-Modell

Ich stelle mir für die Entwicklung einer P2P-Library in C++, die nur aus einem Header und einer Code-Datei besteht, folgendes vor wenn ich an das Wasserfall-Modell denke:

1. **Specification of Requirements:** Schreiben einer RFC für ein P2P-Protokoll.
2. **Design of the Codebase:** Schreiben eines Headers inklusive Doxygen-Kommentaren.
3. **Implementation of the Codebase:** Schreiben einer Code-Datei inklusive Unit-Tests.
4. **Testing of the Codebase:** Durchführen von Code Coverage und Statischer Analyse.
5. **Documentation of Everything:** Anfertigen ergänzender Seiten für Doxygen.
6. **Repetition of previous Steps:** IF NOT (nothing to do) THEN GOTO 1.

## Das Leiter-Modell (mein Schatz)

Ich muss sagen dass Zustand (6) nicht ganz der Realität entspricht. Tatsächlich kann es eine Vielzahl von Spezialfällen geben die als Übergang zwischen den Phasen (1) bis (5) auftreten.  Als Schaubild sehe das folgendermaßen aus (aus Sicht eines Solo-Entwicklers).

```
  Start                        Stop
    v                            ^
====================         ====================
= 1. Spacification = ------> = X. Special Cases =
==================== <------ ====================
    |^                       = - Backup Case    =
    v|                       = - Break Case     =
=============                = - Change Case    =
= 2. Design = -------------> = - Clash Case     =
============= <------------- = - Commit Case    =
    |^                       = - Language Model =
    v|                       =   Chat Case      =
=====================        = - Migration      =
= 3. Implementation = -----> =   Case           =
===================== <----- = - Next Version   =
    |^                       =   List Case      =
    v|                       = - Work Done Case =
==============               = - ...            =
= 4. Testing = ------------> =                  =
============== <------------ =                  =
    |^                       =                  =
    v|                       =                  =
====================         =                  =
= 5. Documentation = ------> =                  =
==================== <------ ====================
```

Mit den Pfeilen vom linken zum rechten Teil des Schaubildes und zurück sieht das Leiter-Modell eben aus wie eine Leiter. Aber ich gestehe offen, dass ich vom neulich erschienenen und zwei mal durchgespielten [Silent Hill 2 Remake](https://en.wikipedia.org/wiki/Silent_Hill_2_(2024_video_game)) beeinflußt sein könnte. Das ich beim [zweiten Durchgang](https://youtu.be/21csgRGxGAc?si=-NT0hEyeRtTzGCQl) voll auf meinen Youtube-Spiele-Kanal hochgeladen habe. Ich erfuhr zudem vor einigen Wochen dass die Silent-Hill-Reihe auf dem Film [Jacob's Ladder](https://en.wikipedia.org/wiki/Jacob%27s_Ladder_(1990_film)) von 1990 basiert, den ich dann so gleich geguckt habe. Deswegen nenne ich das Leiter-Modell auch gerne Bogdans Leiter.

## Erläuterungen zu den Phasen und Zuständen

Die Zustände des Leiter-Modells können wie folgt erläutert werden.

- (A) **Start:** Bei diesem Zustand ist man bevor man mit der Arbeit beginnt. Theoretisch kann es zwischen Start und Stop im realen Leben ein Hin und Her geben. Aber das hat vermutlich nichts mit Software-Entwicklung zu tun. Deswegen sind keine Pfeile eingezeichnet.
- (1) **Specification:** Bei Auftragsarbeit muss ein Lastenheft angefertigt werden. Wenn das eine Auftragsarbeit von Extern ist, wird das der Auftraggeber anfertigen und dem Auftragnehmer aushändigen. Es könnte aber auch so etwas wie ein RFC sein für das eine Referenz-Implementation zu bauen ist.
- (2) **Design:** In dieser Phase geht es technischer/konkreter zu als bei der Spezifikation. Man klärt Klassen, Methoden, freie Funktionen. Das kann wie in C/C++ das Anfertigen von Headern sein und von leere Code-Rümpfen (Stubs genannt). Damit die Codebase, wenn auch nicht funktionsfähig, doch wenigstens kompilierbar ist.
- (3) **Implementation:** Dies dürfte die langwierigste Phase sein. In C/C++ wäre das das Schreiben der Code-Rümpfe die sich zumeist in Code-Dateien (.cpp) befinden. Es sei denn es handelt sich um eine header-only Library bspw. weil alles Templates sind und diese (meistens) nur in Headern platzierbar sind. Die Implementation beinhaltet auch das Anfertigen von Unit-Tests.
- (4) **Testing:** In dieser Phase wird sich um solche Dinge wie Code Coverage und Statische Analyse gekümmert. Die Dynamische Analyse ist eigentlich nur Erforderlich wenn bspw. während der Laufzeit schwere Fehler auftreten, bspw. mit Race Conditions bei Multithreading.
- (5) **Documentation:** In dieser Phase wir sichergestellt dass Dokumentationen wie bspw. mit Doxygen, Sphinx oder Mediawiki vollständig sind.
- (X) **Special Cases:** Dieser Zustand bündelt eine ganze Menge von Zuständen die sonst einzeln gezeichnet und mit Pfeilen versehen sein müssten. Es wurden einige, aber sicher nicht alle Spezialfälle aufgezählt.
    - **Backup Case:** Es ist sehr empfehlenswert, dass jeder Entwickler auf seinem Rechner zwischendurch lokal zusätzliche Backups anfertigt. Denn nicht immer hat man etwas ins zentrale Repo auf einem Server hochgeladen. Und Firmen-Backup findet vermutlich nur alle 24 Stunden statt.
    - **Break Case:** Man muss auch mal Pause machen. Aber je länger die Pause, bspw. wegen Wochenende oder Urlaub, desto länger muss man sich Einarbeitet und landet dann wohl bei Zustand Start (A). Das nennt man Overhead, gibt es in jedem Beruf, kostet überall Zeit, Geld und Nerven.
    - **Change Case:** Es kann sein, dass man in einen anderen Zustand (1) bis (5) übergehen muss, weil sich ein Änderung oder viel eher ein Änderungswunsch zwischendurch ergeben hat.
    - **Clash Case:** Ein Clash kann aus den unterschiedlichsten Gründen stattfinden. Meistens ist das, weil etwas nicht commitet werden kann (bspw. Repo-Addresse geändert) oder bei einem Update Case und man erst mergen muss.
    - **Commit Case:** Beim Commit ist es so dass man evtl. aufwändig (mit Code durchgehen) feststellen muss was alles geändert wurde und was man davon in die Commit-Message und evtl. den Changelog aufnehmen will.
    - **Language Model Chat Case (LM-Chat):** Man kann sich in jeder Phase (1) bis (5) mit seinen Team-Kollegen austauschen. Nur als Solo-Kämpfer kann man das nicht. In der Ära der schmalen Taschen und gebrochenen Herzen kann es hilfreich sein Pair Programming mit einem lokalen Replikanten zu praktizieren. Wenn man weiß wie man seine Dummheit und Gefährlichkeit in den Griff bekommt. Das Beste wo Kollege C3PO taugt sind Feedback, Rückfragen und Vorschläge. Alles andere kann so gefährlich sein, dass es zu einer geleerten 2-TB-SSD führt die ~ich~ man Tage lang durchsuchen/retten darf.
    - **Migration Case:** Es kommt gelegentlich vor, dass ein Entwickler auf die Idee kommt sein ausgechecktes Zeug wo anders zu entwickeln. Er könnte vielleicht der Meinung sein die Backups durch Snapshots einer VM ersetzen zu können. Worauf hin er eine VM (bspw. libvirt + virt-manager unter Linux) auf seinem Entwicklungs-Rechner aufsetzt und dort weiter entwickelt. Kluger Junge! Fast, denn er sollte Backups seiner VMs machen. Was er gewinnt ist Bequemlichkeit um andere Snapshots schnell mal starten zu können.
    - **Next Version List Case (NV-List):** Zwischendurch stellt man fest, dass man sich zu viel für die aktuelle Version vorgenommen hat. Das schiebt man dann auf eine Liste für die nächste Version. Es heißt List und nicht Backlog, weil man vermutlich hier nicht gleich ausführlich Plant für die nächste Version. Ein alternativer Begriff wäre Heap.
    - **Work Done Case:** In diesem Zustand landet man hoffentlich irgendwann nach Phase Documentation (5). Wenn nämlich alle Arbeit für die gerade in Entwicklung befindliche Version getan wurde. Mal abgesehen von der auf der NV-List für die nächste Version. Denn eigentlich ist immer was zu tun. Die angenehmste Arbeit wartet in der Zukunft, außer man hat Scheiße gebaut.
- (O) **Stop:** Bei diesem Zustand landet man, wenn man trotz aller Loops durch die Phasen (1) bis (5) keine Arbeit mehr findet. Oder wenn einem Zeit oder Geld oder Nerven ausgegangen sind. Im Grunde landet man hier direkt, wenn man sich im Spezialfall Work Done Case befunden hat. Aber wie schon bei der Erklärung zum Zustand Start (A) erwähn, kann es im realen Leben u.U. doch einen Rückweg von Zustand Stop (O) nach Zustand Start (A) geben. Und es ist ganz sicher Zustand Start (A) und kein anderer, weil man sich erst wieder rein fuchsen muss.

## Fazit

Ich werde künftig statt nach Wasserfall- lieber nach diesem Leiter-Modell entwickeln. Mit den Spezialfällen die weder im Wasserfall-Modell noch im V-Modell vorkommen, gibt das Leiter-Modell einen realistischeren Blick auf die Software-Entwicklung. Selbst so etwas wie die Nutzung von Sprachmodellen für Pair Programming wird mit dem Leiter-Modell leicht abgebildet. Die Konkretisierung der Phasen (1) bis (5) und der Phase für Spezialfälle (X) ist jedem Solo-Entwickler oder jedem Team selbst überlassen. Die Bedürfnisse und Geschmäcker sind nun mal sehr unterschiedlich. Das Leiter-Modell dient als anpassbare Schablone.