Eine geerbte Qt-Anwendung soll weiterlaufen, doch für Wartung, Tests und Releases gibt es weder belastbare Schätzungen noch viel Budget. Meine Position: Ein kleiner Etat rechtfertigt einen kleineren Freigabeumfang, aber keine abgespeckte Absicherung für die Änderungen, die tatsächlich ausgeliefert werden. Wer beides verwechselt, beauftragt scheinbar günstige Entwicklung und trägt das unbezifferte Ausfallrisiko selbst.
Ein kleines Budget muss den Release begrenzen, nicht die Sorgfalt
Für die Kalkulation nehme ich eine bestehende Qt-Desktop-Anwendung an, deren Quellcode vorliegt und die unter Windows und Linux ausgeliefert wird. Die konkreten Plattformen sind hier eine veränderbare Projektannahme: Schon eine zusätzliche Zielumgebung verändert Build, Paketierung und Abnahme. Der erste Auftrag an das Team sollte deshalb nicht „Qt modernisieren“ lauten, sondern beispielsweise: „Der Import einer Datei wird korrigiert und mit der nächsten Windows-Version ausgeliefert; Linux bleibt unverändert.“ Das ist ein kleinerer Auftrag mit überprüfbarer Grenze.
Vor einer Zusage braucht der Product Manager drei Antworten: Welche ausführbare Version nutzen die Kunden tatsächlich? Wie wird daraus heute ein installierbares Paket? Welcher Fehler oder welche Änderung rechtfertigt den Release? Ein Git-Repository beantwortet die zweite Frage nicht, weil ein erfolgreicher Commit weder die passende Qt-Laufzeit noch ein funktionierendes Installationspaket belegt. Fehlen Build-Anleitung oder Abhängigkeiten, gehören deren Rekonstruktion und ein einmaliger Referenz-Build ausdrücklich zum Umfang.
Ich würde keine Qt-6-Migration als Nebenbedingung einer kleinen Fehlerkorrektur beauftragen, weil API-Änderungen, Plugins und Paketierung die Fehlerursache verdecken und die Abnahme vergrößern können. Steht die Anwendung noch auf Qt 5.15.2, ist „auf Qt 6.5 bringen“ ein eigenes Vorhaben mit eigener Kompatibilitätsprüfung, nicht ein kostenloser Qualitätsbonus. Ebenso würde ich keine plattformübergreifende Freigabe versprechen, wenn nur auf Windows ein reproduzierbarer Installer entsteht.
Der günstige Weg ist damit nicht, Arbeit stillschweigend wegzulassen. Er benennt ausdrücklich, was nicht freigegeben wird: weitere Betriebssysteme, neue Funktionen außerhalb des Fehlers und eine allgemeine Bereinigung alter Module. Diese Grenze schützt auch das Team, weil jede spätere Erweiterung wieder geschätzt werden muss, statt in einer vagen Zusage zu verschwinden.
Die erste Ausgabe muss das Änderungsrisiko sichtbar machen
Den Beitrag Geerbtes Qt ohne Tests GUI Tests sind der falsche Start würde ich nicht als Budgetvorlage verwenden, weil die richtige Testart allein noch nicht festlegt, welche Änderung bezahlt und freigegeben wird. Für die Planung ist zunächst ein enger Änderungspfad nötig: Eingabedatei, Verarbeitung, gespeicherter Zustand und sichtbares Ergebnis. An diesem Pfad lässt sich erkennen, welche Teile der Anwendung die Korrektur berührt und welche Beobachtungen nachher tatsächlich etwas beweisen.
Bei einer Qt-Anwendung können dafür Qt Test und QSignalSpy gezielt Signale und Zustandswechsel prüfen. Ein Import, der Daten in SQLite speichert, braucht zusätzlich einen Test des geschriebenen Ergebnisses; ein grünes Signal sagt nichts darüber aus, ob die Datenbank anschließend verwendbar ist. Für eine bereits vorhandene Kundendatenbank kann PRAGMA integrity_check Teil einer separaten Diagnose sein, weil ein frischer Testdatensatz Schäden an alten Dateien nicht sichtbar macht. QSettings verdient einen eigenen Blick, sobald Pfade oder Optionen über Releases hinweg erhalten bleiben müssen.
Der Umfang bleibt trotzdem begrenzt. Als vorläufigen, im Projekt anpassbaren Zielwert würde ich zwei automatisierte Prüfungen für den geänderten Verarbeitungspfad und eine manuelle Installation auf einer sauberen Zielmaschine vereinbaren. Die Zahl ist keine Qualitätsnorm: Wenn der Fehler nur mit einer alten Datenbank reproduzierbar ist, kann ein belastbarer Regressionstest wertvoller sein als mehrere neue Kleintests. Der Product Manager sollte deshalb nach dem abgedeckten Risiko fragen, nicht nach der größten Testzahl.
Zur ersten Bestandsaufnahme gehören außerdem ein festgehaltener Commit, die verwendeten Compiler- und Qt-Versionen sowie ein reproduzierbarer Build-Befehl. CMake und CTest liefern dafür eine gemeinsame Ausführungsstelle, sofern das Projekt bereits darauf aufbaut oder die Umstellung klein bleibt. Ist der vorhandene Build dagegen qmake-basiert, würde ich CMake nicht nur für eine schöne Pipeline einführen, weil der Wechsel selbst neue Buildfehler erzeugen kann. In diesem Fall wird der bestehende Build zunächst dokumentiert und die Testausführung passend dazu angebunden.
Ein billiger Patch und ein belastbarer Release sind verschiedene Angebote
Für die Entscheidung würde ich zwei ausdrücklich benannte Optionen anbieten. Option A: begrenzter Patch gewinnt, wenn der Fehler reproduzierbar ist, nur ein Verarbeitungspfad geändert wird und der Kunde eine eingeschränkte Plattformfreigabe akzeptiert. Als veränderbaren Kalkulationswert setze ich zwölf Entwicklungstage zu 850 Euro und drei QA-Tage zu 650 Euro an. Mit einer ebenfalls verhandelbaren Reserve von 20 Prozent ergibt das 14.580 Euro. Das Angebot bezahlt Diagnose, Korrektur, gezielte Regressionstests und eine definierte Abnahme; es bezahlt keine allgemeine Modernisierung.
Option B: belastbarer Release-Prozess gewinnt, wenn regelmäßig Änderungen folgen, mehrere Zielsysteme versorgt werden oder niemand die bisherige Paketierung verlässlich wiederholen kann. Für einen ersten Zuschnitt rechne ich mit 30 Entwicklungstagen, acht QA-Tagen und vier weiteren Entwicklungstagen für Build und Release, jeweils zu denselben angenommenen Tagessätzen. Einschließlich der veränderbaren Reserve von 20 Prozent ergibt das 40.920 Euro. Das ist kein Marktpreis, sondern eine offengelegte Rechnung, die nach Sichtung des Repositories korrigiert werden muss.
Option B kauft nicht einfach „mehr Tests“. Sie kauft eine definierte Build-Umgebung, dokumentierte Abhängigkeiten, wiederholbare Artefakte und eine Abnahme für die vereinbarten Plattformen. GitHub Actions kann Builds ausführen; ein grüner Lauf dort beweist aber noch nicht, dass ein Windows-Installer auf einem Rechner ohne Entwicklerwerkzeuge startet. Dafür braucht es einen gesonderten Installationstest. Wird MSIX oder WiX Toolset v4 für das Paket verwendet, müssen die tatsächlichen Installations- und Updatewege geprüft werden, weil Fehler dort vom erfolgreichen Kompilieren unabhängig sind.
Die Optionen sollte man nicht zu einem scheinbar günstigen Mittelweg vermischen. Ein Preis für Option A mit dem Freigabeversprechen von Option B verschiebt unbezahlte Arbeit lediglich in die letzten Projekttage. Umgekehrt ist Option B unnötig groß, wenn nachweislich nur ein einmaliger Patch auf einer kontrollierten Zielumgebung benötigt wird. Die Entscheidung hängt daher an Release-Häufigkeit und akzeptiertem Restrisiko, nicht am Wunsch nach einer möglichst niedrigen Angebotszeile.
Eine Pipeline zählt erst, wenn sie einen realen Defekt stoppen kann
Den Beitrag Qt Entwicklung Tipps fuer robuste Desktop Apps würde ich als technisches Korrektiv lesen, nicht als Abnahmekatalog, weil robuste Implementierung und ein überprüfbarer Lieferprozess unterschiedliche Nachweise brauchen. Für den vereinbarten Änderungspfad sollte die Pipeline mindestens bauen, die registrierten Tests ausführen und bei einem Fehler abbrechen. Unter Linux mit installierten Qt- und Compiler-Abhängigkeiten könnte ein bereits auf CMake und CTest eingerichtetes Teilprojekt so geprüft werden:
#!/usr/bin/env bash set -euo pipefail cmake -S . -B build-check -DCMAKE_BUILD_TYPE=Debug \ -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \ -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address,undefined" cmake --build build-check --parallel 2 ASAN_OPTIONS=detect_leaks=1 ctest --test-dir build-check \ --output-on-failure --timeout 90
Das Skript setzt voraus, dass die Tests im Projekt mit CTest registriert sind; ohne solche Tests wäre ein erfolgreicher Lauf keine sinnvolle Absicherung. AddressSanitizer und UndefinedBehaviorSanitizer können Speicher- beziehungsweise undefinierte Zugriffe im ausgeführten Code aufdecken, erfassen aber keine Pfade, die der Test nicht betritt. Das Zeitlimit von 90 Sekunden ist ein zu justierender Pipeline-Wert, keine gemessene Eigenschaft der Anwendung. Auch der Parallelwert zwei begrenzt hier nur die gleichzeitigen Build-Aufträge und sollte zur verfügbaren CI-Maschine passen.
Für Windows braucht es zusätzlich einen Build mit der tatsächlich vorgesehenen Toolchain und dem tatsächlichen Qt-Paket, weil ein Linux-Erfolg keine Aussage über Windows-Plugins oder Installer trifft. Vor der Freigabe sollten Paket und Prüfsumme per SHA-256 festgehalten werden. Der Product Manager kann dann ein konkretes Artefakt abnehmen, statt eine unbestimmte „aktuelle Version“. Eine fehlgeschlagene Prüfung muss den Release stoppen dürfen; sonst ist die Pipeline Dokumentation, aber keine Kontrollstelle.
Der Auftrag ist erst klein, wenn auch sein Ende beschrieben ist
Ein Festpreis oder Budgetdeckel funktioniert bei geerbtem Code nur mit einer Regel für unbekannte Befunde. Beispielsweise kann das Team nach der Bestandsaufnahme melden, dass ein benötigtes Qt-Plugin nicht mehr verfügbar ist oder die Kundendatenbank vor dem Import migriert werden muss. Beides verändert den Auftrag, weil dann nicht mehr nur die ursprünglich beauftragte Korrektur zu liefern ist. Für solche Befunde braucht es eine Entscheidung: Umfang reduzieren, Budget erhöhen oder Release verschieben.
Ich würde die Abnahme in einem kurzen Arbeitsblatt festhalten: Ausgangsversion und Zielplattform, reproduzierbarer Fehler, erwartetes Ergebnis, benötigte Testdaten, Build- und Installationsweg sowie die Person, die das Ergebnis fachlich bestätigt. Dazu gehört eine Rückfallregel. Wenn ein Update scheitert, muss geklärt sein, ob der alte Installer erneut eingespielt werden kann und ob Datenformatänderungen dies verhindern. Gerade diese Frage kann aus einem kleinen Patch einen größeren Release machen, weil eine Datenmigration nicht durch das Zurückkopieren einer Programmdatei rückgängig wird.
Offene Punkte erhalten einen Eigentümer und einen Entscheidungstermin, nicht die Kennzeichnung „später prüfen“. Eine Qt-Version ohne gesicherte Bezugsquelle, ein fehlendes Signaturzertifikat oder ein nur auf Entwicklerrechnern funktionierender Installer sind keine kosmetischen Restarbeiten, weil sie die Auslieferung blockieren können. Wer sie im Angebot ausklammert, sollte auch den Release davon ausklammern. Diese Trennung mag unbequem sein; sie ist ehrlicher als ein Termin, dessen technische Voraussetzungen niemand geprüft hat.
Lassen Sie als Erstes einen Entwickler den aktuellen Stand auf einer sauberen Maschine bauen und das entstandene Paket installieren. Beauftragen Sie dafür einen begrenzten Befund statt sofort eines Modernisierungssprints. Mit Build-Protokoll, reproduziertem Fehler und dokumentierten Blockern können Sie anschließend zwischen Patch und belastbarem Release-Prozess entscheiden – und den Umfang unterschreiben, den Ihr Budget tatsächlich trägt.
