MASTER-ENTWICKLUNGSAUFTRAG
AIRBUS A380 FÜR MICROSOFT FLIGHT SIMULATOR 2024
Konsolidierte Fassung aus vier Entwicklungstexten:
1. Recherche- und Entwicklungsauftrag mit professionellem Qualitätsanspruch
2. Maximaler sinnvoller Werkzeugeinsatz und Hardwareoptimierung
3. Realitätsnähe, genaue Daten, Testphasen, Logs und Bugberichte
4. Integriertes Electronic Flight Bag (EFB)
======================================================================
1. HAUPTZIEL UND QUALITÄTSANSPRUCH
======================================================================
Entwickle einen möglichst realistischen, stabilen, gut dokumentierten und leistungsoptimierten Airbus A380 für Microsoft Flight Simulator 2024 (MSFS 2024). Orientiere dich bei Systemtiefe, Zuverlässigkeit, Bedienbarkeit, Modellqualität und Qualitätssicherung an professionellen, detaillierten Payware-Flugzeugen, beispielsweise als Qualitätsreferenz an Fenix. Diese Orientierung ist ein Anspruch an die Qualität, keine Garantie für gleichwertige Ergebnisse und keine Erlaubnis, proprietären Code, geschützte Modelle, Texturen, Sounds oder interne Implementierungen anderer Entwickler zu kopieren.
Das Ziel ist kein bloßes Außenmodell mit vereinfachtem Flugverhalten. Das Projekt soll nach und nach ein modulares Flugzeug mit nachvollziehbarem Flugmodell, interaktivem Cockpit, funktionalen Systemen, Avionik, Flugmanagement, realistischen Betriebsabläufen, Diagnosefunktionen und einem integrierten Electronic Flight Bag (EFB) erhalten.
Arbeite in überprüfbaren Schritten. Qualität, technische Glaubwürdigkeit, Schutz bestehender Installationen und nachgewiesene Funktionalität haben Vorrang vor schnellen Erfolgsmeldungen.
Das Projekt ist langfristig angelegt. Plane den Code so, dass Fortschritt über mehrere Sitzungen hinweg sicher nachvollzogen und die Arbeit später zuverlässig fortgesetzt werden kann. Versprich keine unbegrenzte Hintergrundarbeit und behaupte nicht, dass Arbeiten in einer späteren Sitzung oder ohne tatsächlichen Test bereits ausgeführt wurden.
======================================================================
2. VERBINDLICHE ARBEITS- UND SICHERHEITSREGELN
======================================================================
2.1 Zuerst Bestandsaufnahme, dann Planung, erst danach Änderungen
Beginne mit einer dokumentierten Bestandsaufnahme der tatsächlich verfügbaren Umgebung, Werkzeuge, SDK-Version, Projektdateien, Build-Konfiguration und Abhängigkeiten. Erstelle zunächst einen Recherche- und Prüfplan. Verändere im ersten Schritt keine vorhandenen Dateien, keine Simulatoroptionen und keine Systemkonfiguration.
2.2 Getrennte Entwicklungsumgebung
Arbeite in einer eigenen, klar getrennten Projektablage. Schütze die bestehende MSFS-Installation und vorhandene Add-ons, insbesondere Fenix, FlyByWire, GSX, BeyondATC, MobiFlight und weitere Community-Inhalte. Ändere, lösche oder überschreibe deren Dateien nicht ohne ausdrückliche Freigabe.
2.3 Backups und Wiederherstellung
Vor jeder genehmigten riskanten Änderung:
- Bestand und betroffene Dateien erfassen.
- Backup mit Zeitstempel erstellen.
- Backup auf Vollständigkeit und Lesbarkeit prüfen.
- Änderungen dokumentieren.
- Nach der Änderung prüfen, ob das Ergebnis korrekt ist.
- Einen getesteten Rückweg vorsehen, falls eine Änderung fehlschlägt.
Keine Installation, Treiber-, BIOS-, Registry-, Windows- oder globalen MSFS-Änderungen ohne nachvollziehbare Notwendigkeit und ausdrückliche Zustimmung vornehmen.
2.4 Tatsachen, Schätzungen und Testergebnisse trennen
Erfinde keine technischen Daten, Quellen, Werkzeuge, Dateien, Messwerte, Testergebnisse oder implementierten Funktionen. Kennzeichne jederzeit eindeutig:
- bestätigt und mit Quelle belegt;
- durch mehrere Quellen plausibilisiert;
- in der Entwicklungsumgebung beobachtet oder gemessen;
- geschätzt oder vorläufig angenommen;
- unbekannt bzw. nicht überprüfbar.
Ein erfolgreicher Build beweist nicht, dass das Flugzeug korrekt im Simulator funktioniert. Ein Quellcodecheck ersetzt keinen Simulatorlauf. Behaupte keinen FPS-Wert, Test, Build oder Integrationsnachweis, der nicht tatsächlich ausgeführt wurde.
2.5 Blockaden offen dokumentieren
Wenn ein Zugriff, Werkzeug, Datenbestand, Berechtigung oder Testsystem nicht verfügbar ist, benenne die genaue Blockade. Erledige unabhängige Arbeitsschritte weiter, sofern sie sinnvoll und sicher sind. Erfinde keine Ergebnisse, um eine Lücke zu kaschieren.
======================================================================
3. RECHERCHE, QUELLEN UND DATENGENAUIGKEIT
======================================================================
Führe vor der Implementierung gründliche Recherche durch. Bevorzuge offizielle und fachlich belastbare Quellen, darunter die offizielle MSFS-2024-SDK-Dokumentation, rechtmäßig zugängliche Herstellerinformationen, technische Veröffentlichungen, nachvollziehbare Open-Source-Projekte und geeignete wissenschaftliche bzw. luftfahrttechnische Quellen.
Nutze unter anderem, sofern relevant und tatsächlich verfügbar:
- Offizielle Microsoft Flight Simulator 2024 SDK-Dokumentation.
- Offizielle Airbus-Informationen und öffentlich zugängliche A380-Daten.
- Dokumentationen und Beispiele für zulässige SDK-Funktionen.
- Git-Repositories und Open-Source-Projekte mit passenden Lizenzen.
- Blender und weitere rechtmäßig nutzbare Werkzeuge für 3D-Modellierung.
- Build-, Validierungs-, Test- und Diagnosewerkzeuge.
- Fachliteratur und geeignete öffentliche Referenzdaten.
Prüfe jede Quelle auf Relevanz, Aktualität, Herkunft und Lizenzbedingungen. Verwechsle Daten anderer A380-Versionen, anderer Flugzeuge oder anderer Simulatoren nicht mit verifizierten Daten für die geplante Variante.
Führe für jeden relevanten technischen Datenpunkt ein Daten- und Quellenregister mit mindestens:
1. Kennung und Bezeichnung des Parameters.
2. Wert und Einheit.
3. Betroffene Variante und Betriebsbedingung.
4. Quelle, Link und Fundstelle.
5. Datum der Prüfung.
6. Vertrauensstatus.
7. Verwendung im Projekt.
8. Offene Fragen oder Validierungsbedarf.
Verwende folgende Evidenzklassen:
A – offizielle, direkt passende Quelle;
B – zuverlässige technische Quelle bzw. offizielles SDK-Verhalten;
C – glaubwürdige, indirekte oder sekundäre Quelle;
D – eigene Messung, Simulatorbeobachtung oder experimenteller Test;
E – Schätzung, Hypothese oder nicht verifizierte Annahme.
Diese Klassen sind keine automatische Qualitätsgarantie. Erläutere bei wichtigen Parametern, warum eine Einstufung gewählt wurde. Wo genaue Originaldaten nicht öffentlich verfügbar sind, kennzeichne die Datenlücke und entwickle allenfalls ein transparentes, eigenständiges Simulationsmodell mit dokumentierten Annahmen.
Wichtige Recherchebereiche:
- Abmessungen und Außenmodell.
- Aerodynamik, Gewichte und Schwerpunkt.
- Flugsteuerung und bewegliche Flächen.
- Triebwerke und Schubverhalten.
- Fahrwerk, Lenkung und Bremsen.
- Elektrik und Hydraulik.
- Treibstoff und Verbrauch.
- Druckkabine und Klimatisierung, soweit sinnvoll umsetzbar.
- Avionik, Navigation, Autopilot und Flugmanagement.
- Cockpitanzeigen, Warnungen, Sounds, Beleuchtung und Animationen.
- Bedienabläufe, Fehlermodi und Simulationsgrenzen.
======================================================================
4. VARIANTEN UND PROJEKTUMFANG
======================================================================
Plane eine gemeinsame technische Basis und trenne Varianten über klare Konfigurationen und Module.
Priorität 1:
- A380-800 als Basisflugzeug.
- A380-800 mit Rolls-Royce-Trent-900-Konfiguration, soweit verlässliche Daten verfügbar sind.
- A380-800 mit Engine-Alliance-GP7200-Konfiguration, soweit verlässliche Daten verfügbar sind.
- Unterschiedliche Kabinenlayouts, Gewichts- und Betriebsvarianten sowie Lackierungen, wenn Daten und Ressourcen dies erlauben.
Jede Variante soll die für sie geltenden Daten und Grenzen verwenden. Triebwerkscharakteristik, Gewichte, Anzeigen und Konfigurationen dürfen nicht unkontrolliert vermischt werden.
Nicht in Serie gebaute bzw. konzeptionelle Varianten wie A380-700, A380-900 oder A380F dürfen nur als klar gekennzeichnete experimentelle bzw. hypothetische Simulationen aufgenommen werden. Stelle sie nicht als serienmäßig gebaute A380-Versionen dar. Dokumentiere dafür die Datenlücken und Unsicherheiten. Baue zuerst eine solide, getestete Basisvariante, bevor der Umfang auf weitere Varianten ausgeweitet wird.
======================================================================
5. MODULARE ARCHITEKTUR
======================================================================
Entwickle eine nachvollziehbare Architektur mit klaren Verantwortlichkeiten, Schnittstellen und Abhängigkeiten. Mindestens folgende Module sind vorzusehen, soweit die jeweilige Funktion technisch umsetzbar ist:
- Aircraft Core und Zustandsverwaltung
- Außenmodell und Animationen
- Cockpit und interaktive Bedienelemente
- Flugmodell und Aerodynamik
- Flight Controls / Flugsteuerung
- Triebwerkssystem
- Fahrwerk, Lenkung und Bremsen
- Elektrisches System
- Hydrauliksystem
- Treibstoffsystem
- Avionik und Cockpitanzeigen
- Navigation und Flugmanagementsystem (FMS)
- Autopilot und Flugmodi
- Beleuchtung und Materialien
- Soundsystem
- EFB
- Konfiguration und Varianten
- Diagnose und Logging
- Automatisierte Tests
- Performanceüberwachung
- Datavalidierung
- Backup, Versionierung und Wiederherstellung
Definiere für jedes Modul Zweck, Datenmodell, Schnittstellen, Voraussetzungen, Fehlerfälle, Tests und Akzeptanzkriterien. Vermeide zyklische Abhängigkeiten und doppelte Wahrheiten über denselben Flugzeugzustand. Kritische Zustandswerte sollen eine eindeutig definierte Quelle besitzen.
======================================================================
6. REALISTISCHES FLUGVERHALTEN UND FLUGZEUGSYSTEME
======================================================================
Das Flugzeug soll nicht nur optisch realistisch sein. Implementiere und überprüfe das Flugverhalten und die Systemfunktionen stufenweise.
Flugmodell und Flugverhalten:
- Masse, Schwerpunkt und Trägheitsverhalten.
- Auftrieb, Widerstand und Steuerreaktionen.
- Trimmung und Stabilität.
- Vorflügel, Klappen, Spoiler und Ruder.
- Start, Steigflug, Reiseflug, Sinkflug, Anflug und Landung.
- Verhalten bei relevanten Wetter- und Gewichtsbedingungen.
- Langsamflug und Überziehverhalten, soweit belastbar modellierbar.
Systeme:
- Triebwerksstart, Betrieb und Abschaltung.
- Plausibles Schubverhalten und Anzeigen.
- Fahrwerk, Bremsen, Bodenlenkung und Bodenverhalten.
- Elektrische Versorgung und definierte Systemzustände.
- Hydraulik, soweit technisch implementiert.
- Treibstoffbestand, Verteilung und Verbrauch.
- Autopilot-Modi, Moduswechsel und Flugführungsfunktionen.
- Navigation, Flugplanverarbeitung und FMS-Funktionen.
- Cockpitanzeigen, Warnungen und erkennbare Systemausfälle.
Vergleiche Messwerte nur bei vergleichbaren Randbedingungen. Berücksichtige beispielsweise Masse, Schwerpunkt, Klappenstellung, Flughöhe, Temperatur, Wind, Druckhöhe und Konfiguration. Dokumentiere Abweichungen und untersuche sie, statt Werte künstlich an Erwartungen anzupassen.
Wenn ein System nur teilweise implementiert wird, kennzeichne den Umfang klar. Behaupte nicht, ein System entspreche vollständig der realen Airbus-Implementierung, wenn dies nicht nachgewiesen werden kann.
======================================================================
7. INTEGRIERTES ELECTRONIC FLIGHT BAG (EFB)
======================================================================
Das EFB ist ein eigenständiger, integrierter Entwicklungsbereich und soll nicht bloß eine dekorative Tablet-Oberfläche sein. Es soll relevante Daten aus klar definierten Quellen anzeigen und nur kontrollierte, validierte Eingaben an Flugzeugmodule übergeben.
7.1 Grundfunktionen
- Startseite und Flugzeugstatus.
- Flugvorbereitung und Flugplanübersicht.
- Abflug-, Ankunfts- und Flughafeninformationen, soweit verfügbar.
- Gewichts- und Schwerpunktübersicht.
- Treibstoffplanung und Verbrauchsvergleich.
- Start- und Landungs-Performancefunktionen im Umfang eines transparenten Simulationsmodells.
- Interaktive Checklisten.
- Konfiguration und Benutzerprofile.
- Systemmeldungen, Diagnose und Fehlerübersicht.
- Versions-, Quellen- und Datenstatus.
7.2 Flugplanung
- Abflug, Ziel und Ausweichflughafen auswählen.
- Route anzeigen und bearbeiten.
- Wegpunkte und geplante Höhen/Geschwindigkeiten darstellen.
- Geplante Flugzeit und Treibstoffschätzung berechnen, soweit Daten ausreichend sind.
- Flugplan auf Vollständigkeit und Plausibilität prüfen.
- Import unterstützter Formate untersuchen; SimBrief-Import nur dann vorsehen, wenn Schnittstellen, technische Voraussetzungen und Nutzungsbedingungen geklärt sind.
- Datenherkunft kennzeichnen: importiert, berechnet oder manuell eingegeben.
7.3 Gewicht und Schwerpunkt
- Betriebsleergewicht, Passagier-, Gepäck-, Fracht- und Treibstoffgewicht darstellen.
- Gesamtgewicht, Nutzlast und Schwerpunkt berechnen, soweit passende Daten vorliegen.
- Eingaben validieren und Überschreitungen definierter Grenzen melden.
- Werte mit dem simulierten Flugzeugzustand synchronisieren.
- Annahmen und nicht verifizierte Daten sichtbar kennzeichnen.
7.4 Treibstoffplanung
- Geplanten Bedarf und Reserve darstellen.
- Aktuellen simulierten Treibstoffbestand anzeigen.
- Verbrauch und verbleibenden Treibstoff schätzen.
- Plan- und Ist-Verbrauch vergleichen.
- Ausweichplanung nur im Rahmen verfügbarer und geprüfter Daten unterstützen.
- Unvollständige Eingangsdaten deutlich anzeigen.
7.5 Start- und Landungs-Performance
Untersuche, welche Performancefunktionen mit verfügbaren Daten und Modellen belastbar realisiert werden können. Mögliche Eingaben sind Gewicht, Flugplatzhöhe, Temperatur, Wind, Start-/Landebahn und Flugzeugkonfiguration. Dokumentiere Modellannahmen, Grenzen und Validierungsergebnisse. Erfinde keine originalen Airbus-Algorithmen oder geschützten Herstellerdaten. Kennzeichne eine eigenständige Simulation ausdrücklich als solche und gib keine echten betrieblichen Freigaben vor.
7.6 Checklisten
Plane Checklisten beispielsweise für Cockpit Preparation, Before Start, Engine Start, After Start, Taxi, Before Takeoff, Climb, Cruise, Descent, Approach, Landing, After Landing, Parking und Securing Aircraft.
Unterscheide zwischen automatisch erkannten Zuständen und manuell bestätigten Punkten. Eine Checkliste darf nicht als vollständig abgeschlossen angezeigt werden, wenn benötigte Punkte ungeprüft sind. Kennzeichne eigene Checklisten als Simulation und nicht als offizielle Airbus-Unterlagen, sofern deren Herkunft nicht nachgewiesen ist.
7.7 Integration und Bedienbarkeit
- Klare Schnittstellen zu Flugzeugzuständen und Konfigurationen.
- Validierung und Fehlerbehandlung für jede Eingabe.
- Erkennung fehlender oder widersprüchlicher Daten.
- Eindeutige Status- und Warnanzeigen.
- Lesbare Schrift, klare Navigation und gut bedienbare Schaltflächen.
- Maus- und weitere Eingabegeräte unterstützen, soweit technisch möglich.
- Keine unnötig hohe Aktualisierungsrate oder ressourcenintensive Animationen.
- Performance und Speicherverbrauch des EFB separat messen.
======================================================================
8. HARDWARE- UND PERFORMANCEZIELE
======================================================================
Berücksichtige die bekannte Zielkonfiguration:
- NVIDIA RTX 3060 mit 12 GB VRAM.
- Intel Core i9-10900KF.
- 32 GB RAM.
- MSFS 2024.
- Zielauflösung 1920 × 1080.
Das Ziel ist möglichst flüssige Darstellung mit stabilen Framezeiten. 60 FPS sind ein Entwicklungsziel, keine Garantie für jede Situation. Die tatsächliche Leistung hängt unter anderem von Szenerie, Wetter, Flugzeugkomplexität, Add-ons und Simulatorlast ab.
Miss und dokumentiere, sofern passende Werkzeuge und Daten verfügbar sind:
- Tatsächliche FPS und Framezeiten.
- CPU- und GPU-Auslastung.
- VRAM- und RAM-Verbrauch.
- Ladezeiten und Speicherbedarf.
- Komplexität von Geometrie und Materialien.
- Draw Calls und LOD-Verhalten.
- Aktualisierungsintervalle von Cockpitinstrumenten.
- Performance im Außenmodell und Cockpit.
- EFB-Performance.
- Auswirkungen in großen Flughäfen und bei komplexer Szenerie.
Optimiere erst nach Messung. Verwende geeignete LOD-Stufen, Texturgrößen, Mesh-Komplexität und Aktualisierungsintervalle. Erstelle nach Möglichkeit die Profile „Performance“, „Ausgewogen“ und „Hoch“. Dokumentiere die Auswirkungen jeder Optimierung. Behaupte keine Verbesserungen ohne Vorher-/Nachher-Messung unter vergleichbaren Bedingungen.
======================================================================
9. MINDESTENS 100 HAUPTENTWICKLUNGSSTUFEN
======================================================================
Verwende mindestens die folgenden 100 Hauptstufen als Ausgangsstruktur. Die Stufen dürfen durch Unterstufen erweitert, neu geordnet oder begründet angepasst werden, wenn tatsächliche Abhängigkeiten dies erfordern. Die Anzahl allein ist kein Qualitätsnachweis.
PHASE A – INVENTUR UND PLANUNG
01. Projektauftrag und Umfang konsolidieren.
02. Verfügbare Umgebung und Werkzeuge inventarisieren.
03. SDK- und Simulatorversion erfassen.
04. Bestehende Dateien und Abhängigkeiten nur lesend prüfen.
05. Quellen- und Datenregister einrichten.
06. Lizenz- und Rechteprüfung durchführen.
07. Varianten- und Funktionsumfang festlegen.
08. Risiken und technische Datenlücken dokumentieren.
09. Modularen Architekturentwurf erstellen.
10. Anforderungen und Abnahmekriterien definieren.
PHASE B – PROJEKTGRUNDLAGE
11. Getrennte Projektstruktur anlegen, nachdem die Planung freigegeben ist.
12. Versionsverwaltung einrichten.
13. Backup- und Wiederherstellungsprozess einrichten.
14. Build- und Paketierungsweg dokumentieren.
15. Minimalen Projektbuild erzeugen.
16. Build reproduzierbar prüfen.
17. Logging-Grundlage einrichten.
18. Test- und Bugberichtvorlagen erstellen.
19. Konfigurationsvalidierung einrichten.
20. Erste technische Freigabe der Projektgrundlage.
PHASE C – AUSSENMODELL
21. Außenmodell-Referenzen und Maße dokumentieren.
22. Modellkoordinaten und Maßstab festlegen.
23. Grundrumpf aufbauen.
24. Tragflächen-Grundgeometrie erstellen.
25. Leitwerk erstellen.
26. Triebwerksgrundmodelle integrieren.
27. Fahrwerksgeometrie integrieren.
28. Steuerflächen und bewegliche Bauteile modellieren.
29. Materialien und Texturen erstellen.
30. Modell, Animationen und LODs prüfen.
PHASE D – FLUGMODELL UND STEUERUNG
31. Einheiten- und Parameterkonventionen festlegen.
32. Masse- und Schwerpunktmodell erstellen.
33. Grundlegende aerodynamische Kräfte integrieren.
34. Stabilität und Trimmverhalten untersuchen.
35. Steuerflächen und Eingaben verbinden.
36. Vorflügel und Klappen integrieren.
37. Spoiler und weitere Steuerflächen integrieren.
38. Fahrwerks- und Bodenverhalten testen.
39. Start- und Steigflugtests durchführen.
40. Reiseflug-, Sinkflug- und Landetests durchführen.
PHASE E – TRIEBWERKE UND GRUNDSYSTEME
41. Triebwerkszustände modellieren.
42. Triebwerksstart und -abschaltung implementieren.
43. Schubmodell und relevante Anzeigen verbinden.
44. Triebwerksfehlerfälle prüfen.
45. Treibstoffbestand und Verbrauch integrieren.
46. Treibstoffsystem und Verteilung im verfügbaren Umfang entwickeln.
47. Elektrische Grundversorgung modellieren.
48. Hydraulikgrundfunktionen modellieren.
49. Fahrwerk, Bremsen und Lenkung weiter integrieren.
50. Grundsysteme separat abnehmen.
PHASE F – COCKPIT UND AVIONIK
51. Cockpitgeometrie und Sichtkonzept aufbauen.
52. Instrumente und Anzeigen integrieren.
53. Interaktive Schalter und Bedienelemente umsetzen.
54. Anzeigen an zentrale Flugzeugzustände anbinden.
55. Navigationsdaten und Quellen klären.
56. Flugplanverarbeitung integrieren.
57. FMS-Grundfunktionen entwickeln.
58. Autopilot-Grundfunktionen entwickeln.
59. Moduswechsel und Anzeigen testen.
60. Cockpit- und Avionik-Integration abnehmen.
PHASE G – EFB
61. EFB-Anforderungen und Datenmodell finalisieren.
62. EFB-Grundarchitektur implementieren.
63. EFB-Oberfläche und Navigation erstellen.
64. Flugplanübersicht integrieren.
65. Flugplanimport und Datenvalidierung entwickeln.
66. Gewichts- und Schwerpunktberechnung entwickeln.
67. Treibstoffplanung integrieren.
68. Performancefunktionen transparent modellieren.
69. Interaktive Checklisten integrieren.
70. EFB-Synchronisierung, Fehlerbehandlung und Bedienbarkeit testen.
PHASE H – DETAILFUNKTIONEN
71. Beleuchtungssysteme umsetzen.
72. Außen- und Cockpitanimationen vervollständigen.
73. Soundsystem modular integrieren.
74. Warnmeldungen und Zustandsanzeigen erweitern.
75. Druckkabinen- oder Klimatisierungsfunktionen prüfen und im verfügbaren Umfang umsetzen.
76. Erweiterte Systemzustände integrieren.
77. Relevante Fehlermodi simulieren.
78. Konfiguration und Benutzerprofile vervollständigen.
79. Lackierungen und unterstützte Varianten einbinden.
80. Dokumentierte Funktionsprüfung der Detailfunktionen.
PHASE I – INTEGRATION UND TESTS
81. Gesamtsystemintegration durchführen.
82. Schnittstellen und Datenkonsistenz prüfen.
83. Einzeltests vervollständigen.
84. Integrationstests ausführen.
85. Reproduzierbare Flugphasentests durchführen.
86. Referenzdaten und Simulationsergebnisse vergleichen.
87. Fehlerfälle und ungültige Eingaben testen.
88. Regressionstest-Suite einrichten und ausführen.
89. Performance-Baseline erfassen.
90. Kritische und hohe Fehler bearbeiten.
PHASE J – OPTIMIERUNG UND RELEASE-VORBEREITUNG
91. CPU-Engpässe anhand von Messdaten untersuchen.
92. GPU- und VRAM-Nutzung anhand von Messdaten untersuchen.
93. Geometrie, Texturen und LOD optimieren.
94. Instrumenten- und EFB-Aktualisierung optimieren.
95. Stresstests und längere Stabilitätstests durchführen.
96. Installations- und Wiederherstellungstest durchführen.
97. Dokumentation und bekannte Einschränkungen vervollständigen.
98. Vollständige Regressionstests nach den letzten Änderungen durchführen.
99. Release-Build und Paketstruktur überprüfen.
100. Abnahmebericht erstellen und nächste Roadmap festlegen.
Jede Stufe erhält eine eindeutige ID, Voraussetzungen, Ziele, betroffene Module, konkrete Arbeiten, Tests, Akzeptanzkriterien, Status, Ergebnis, relevante Logs, offene Bugs und einen Abschlussbericht. Eine Stufe darf nur dann als angenommen gelten, wenn ihre vorher definierten Kriterien nachweislich erfüllt sind.
======================================================================
10. VERBINDLICHER TESTPROZESS
======================================================================
Jede Hauptstufe durchläuft, soweit für sie anwendbar, einen dokumentierten Prozess:
1. Anforderungen klären.
2. Voraussetzungen und Abhängigkeiten prüfen.
3. Ausgangszustand sichern.
4. Änderung planen und durchführen.
5. Statische Prüfungen und Validierung durchführen.
6. Einzeltests ausführen.
7. Integrationstests durchführen.
8. Relevante Regressionstests wiederholen.
9. Logs und Messdaten sichern.
10. Fehler bewerten und beheben.
11. Nachtests durchführen.
12. Ergebnisse und Abweichungen dokumentieren.
13. Abnahmeentscheidung treffen.
Verwende mindestens folgende Testarten:
- Quellen- und Datenvalidierung.
- Dateistruktur- und Konfigurationsprüfung.
- Build- und Paketierungstest.
- Einzel- und Integrationstest.
- Flugphasen- und Systemfunktionstest.
- Plausibilitäts- und Referenzvergleich.
- EFB-Eingabe-, Daten- und Synchronisierungstest.
- Fehlerfall- und Grenzwerttest.
- Performance- und Speicherverbrauchstest.
- Kompatibilitäts- und Isolationstest.
- Regressionstest.
- Installations- und Wiederherstellungstest.
- Stabilitäts- und Stresstest.
Teste Szenarien wie Cold-and-Dark, Warmstart, Triebwerksstart, Taxi, Pushback soweit implementiert, Start, Steigflug, Reiseflug, Sinkflug, Anflug, Landung und Abstellen. Nutze dokumentierte Ausgangsbedingungen. Komplexe Flughäfen, schlechtes Wetter und andere Add-ons können als zusätzliche Lastszenarien dienen, sofern Tests sicher und reproduzierbar durchführbar sind.
Nicht ausführbare Tests müssen als NOT RUN oder BLOCKED gekennzeichnet werden. Ein lediglich geplanter Test gilt nicht als ausgeführt.
======================================================================
11. LOGDATEIEN UND DIAGNOSE
======================================================================
Richte ein strukturiertes, nachvollziehbares Logsystem ein, beispielsweise mit folgender Projektstruktur:
Logs/Development/
Logs/Builds/
Logs/Tests/
Logs/Performance/
Logs/EFB/
Logs/Integration/
Logs/Regression/
Logs/Errors/
Logs/Releases/
Jeder relevante Logeintrag enthält nach Möglichkeit:
- Zeitstempel.
- Projektversion und Commit-/Änderungskennung.
- Entwicklungsstufe und Modul.
- Test-ID und Testname.
- Testumgebung und SDK-Version.
- Erwartetes und tatsächliches Ergebnis.
- PASS, FAIL, BLOCKED oder NOT RUN.
- Messwerte und Einheiten.
- Fehlermeldungen und Warnungen.
- Verweise auf Screenshots, Messdateien und weitere Logs.
- Folgemaßnahmen.
Verwende maschinenlesbare Formate wie JSON oder CSV für strukturierte Daten und lesbare Textberichte für Zusammenfassungen. Überschreibe vorherige Logs nicht stillschweigend. Vermeide Passwörter, Zugangsdaten und unnötige vertrauliche Informationen in Protokollen.
======================================================================
12. BUGBERICHTE UND FEHLERNACHVERFOLGUNG
======================================================================
Jeder reproduzierbare Fehler erhält einen eigenen Bugbericht mit:
- Eindeutiger ID, zum Beispiel A380-BUG-0001.
- Titel und Datum.
- Betroffener Version und Modul.
- Schweregrad und Priorität.
- Voraussetzungen und reproduzierbaren Schritten.
- Erwartetem Verhalten.
- Tatsächlichem Verhalten.
- Reproduktionshäufigkeit.
- Zugehörigen Logs und Belegen.
- Vermuteter Ursache, klar als Hypothese markiert.
- Bestätigter Ursache, sofern nachgewiesen.
- Korrektur und betroffenen Dateien.
- Nachtest-Ergebnis.
- Regressionstestergebnis.
- Status und Begründung der Schließung.
Statuswerte:
OPEN, INVESTIGATING, CONFIRMED, FIX IN PROGRESS, FIXED, RETEST REQUIRED, VERIFIED, REOPENED, DEFERRED, WONT FIX.
Schweregrade:
- Kritisch: Absturz, Datenverlust oder grundsätzliche Funktionsunfähigkeit.
- Hoch: zentrale Flugzeugfunktion fehlerhaft.
- Mittel: deutliche Einschränkung einer Funktion.
- Niedrig: kosmetischer oder begrenzter Fehler.
Ein Fehler ist nicht deshalb behoben, weil Quellcode geändert wurde. Er gilt erst dann als VERIFIED, wenn ein geeigneter Nachtest erfolgreich war. Wenn ein Nachtest unmöglich ist, bleibt der Status offen bzw. nicht verifiziert. Führe eine Fehlerliste mit offenen, behobenen, erneut aufgetretenen und zurückgestellten Fehlern.
======================================================================
13. QUALITÄTSBEWERTUNG UND FREIGABEKRITERIEN
======================================================================
Jede Entwicklungsstufe und jedes Modul wird anhand messbarer Kriterien beurteilt:
- Funktionalität.
- Datenqualität und Quellenlage.
- Realitätsnähe und dokumentierte Abweichungen.
- Stabilität.
- Performance.
- Kompatibilität.
- Testabdeckung.
- Fehlerstatus.
- Dokumentationsvollständigkeit.
- Backup- und Wiederherstellbarkeit.
Verwende eindeutige Statuswerte:
NOT STARTED – noch nicht begonnen.
IN PROGRESS – in Bearbeitung.
IMPLEMENTED – implementiert, noch kein vollständiger Testnachweis.
TESTED – Tests wurden ausgeführt; Ergebnis ist dokumentiert.
VERIFIED – Akzeptanzkriterien wurden nachweislich erfüllt.
ACCEPTED – formale Freigabe gemäß Projektkriterien.
BLOCKED – durch eine dokumentierte Abhängigkeit oder fehlende Voraussetzung blockiert.
FAILED – Prüfung fehlgeschlagen.
Die Statuswerte dürfen nicht vermischt werden. Testabdeckung ist nicht dasselbe wie Fehlerfreiheit. Eine Funktion darf nicht als vollständig realistisch bezeichnet werden, wenn nur Teilfunktionen modelliert oder keine geeigneten Referenzen geprüft wurden.
======================================================================
14. FORTSCHRITTSÜBERSICHT UND LANGFRISTIGE WARTUNG
======================================================================
Führe eine zentrale Projektübersicht, die jederzeit zeigt:
- Status aller 100 Hauptstufen und ihrer Unterstufen.
- Implementierte, getestete, verifizierte und akzeptierte Funktionen.
- Offene und fehlgeschlagene Tests.
- Offene Bugs und deren Schweregrad.
- Technische Datenlücken und offene Entscheidungen.
- Blockierte Aufgaben und ihre Ursache.
- Letzten bestätigten Build.
- Letzten erfolgreichen Regressionstest.
- Aktuelle Performance-Baseline.
- Letzten geprüften Sicherungsstand.
- Konkrete nächste Arbeitsschritte.
Führe Änderungsprotokoll, Versionshistorie und Entscheidungsregister. Dokumentiere auch verworfene Ansätze und den Grund ihrer Verwerfung, damit nicht später dieselben Fehlversuche ohne neuen Erkenntnisgewinn wiederholt werden.
======================================================================
15. DOKUMENTATION UND RECHTE
======================================================================
Pflege laufend:
- Architekturhandbuch.
- Daten- und Quellenregister.
- Installations- und Build-Anleitung.
- Testplan und Testergebnisse.
- Logs und Bugberichte.
- Versions- und Änderungsprotokoll.
- Performanceberichte.
- Backup- und Wiederherstellungsanleitung.
- EFB-Funktionsbeschreibung.
- Liste bekannter Einschränkungen.
- Anleitung für Nutzer und Entwickler.
Verwende nur rechtmäßig zugängliche Quellen und entsprechend lizenzierte oder selbst erstellte Modelle, Texturen, Sounds und Codebestandteile. Kopiere keine proprietären Implementierungen oder geschützten Assets. Kennzeichne eigene Checklisten und vereinfachte Simulationen, wenn sie keine offiziellen Herstellerunterlagen darstellen.
======================================================================
16. RELEASE-PROZESS
======================================================================
Erstelle einen Release nicht allein deshalb, weil eine Funktion implementiert wurde. Vor jeder Freigabe müssen die festgelegten Build-, Paket-, Installations-, Funktions- und Regressionstests abgeschlossen oder nicht durchführbare Prüfungen ausdrücklich ausgewiesen sein.
Vor der Freigabe:
- Build erfolgreich ausführen und protokollieren.
- Paketstruktur und Abhängigkeiten prüfen.
- Kritische und hohe Fehler bewerten.
- Regressionstests ausführen.
- Installations- und Wiederherstellungspfad prüfen.
- Dokumentation, Versionsangaben und bekannte Einschränkungen vervollständigen.
- Prüfen, dass keine bestehenden Add-ons unbeabsichtigt verändert wurden.
Der Release-Bericht muss Version, Änderungen, durchgeführte Tests, Testergebnisse, offene Bugs, bekannte Einschränkungen und Installationshinweise enthalten.
======================================================================
17. ERSTER KONKRETER ARBEITSAUFTRAG
======================================================================
Beginne NICHT mit einer ungeprüften Großimplementierung. Führe zuerst eine technische Bestandsaufnahme und strukturierte Recherche aus. Arbeite zunächst nur lesend, sofern keine ausdrückliche Freigabe für Änderungen vorliegt.
Erstelle als erste Ergebnisse:
1. Bestandsaufnahme der tatsächlich verfügbaren Umgebung und Werkzeuge.
2. SDK- und Build-Kompatibilitätsbericht.
3. Quellen- und Datenregister.
4. Technische Architektur und Modulabhängigkeiten.
5. Varianten- und Funktionsumfang.
6. Entwicklungsplan mit mindestens 100 Stufen und Abnahmekriterien.
7. EFB-Funktionsspezifikation.
8. Teststrategie mit reproduzierbaren Testfällen.
9. Log- und Bugberichtsystem.
10. Backup-, Versions- und Wiederherstellungsstrategie.
11. Performanceplan für RTX 3060, i9-10900KF und 32 GB RAM.
12. Risikoregister mit Prioritäten.
13. Liste fehlender Daten und offener Entscheidungen.
14. Bericht über realistisch erreichbaren Umfang und tatsächliche Blockaden.
15. Priorisierte Empfehlung für die erste freizugebende Implementierungsstufe.
Nach Abschluss dieser Bestandsaufnahme stelle die Ergebnisse mit Belegen, offenen Fragen und empfohlenen nächsten Schritten dar. Beginne mit Änderungen erst, wenn sie vom Auftrag gedeckt und notwendige Sicherheitsmaßnahmen erfüllt sind.
======================================================================
18. ABSCHLIESSENDE VERBINDLICHE REGELN
======================================================================
- Nutze alle tatsächlich verfügbaren, geeigneten und autorisierten Werkzeuge; erfinde keine Fähigkeiten.
- Trenne bestätigte Fakten, Messwerte, Schätzungen und Hypothesen.
- Verändere keine bestehenden MSFS-Add-ons ohne ausdrückliche Genehmigung.
- Erstelle und prüfe Sicherungen vor riskanten Änderungen.
- Jede wichtige Funktion braucht Anforderungen und Akzeptanzkriterien.
- Jede relevante Änderung benötigt geeignete Tests.
- Jede Entwicklungsstufe benötigt Logs, Status und Abschlussbericht.
- Jeder reproduzierbare Fehler benötigt eine Bug-ID und Nachverfolgung.
- Führe nach relevanten Änderungen Regressionstests aus.
- Melde nur tatsächlich ausgeführte Builds und Tests als ausgeführt.
- Dokumentiere nicht verfügbare Daten, Werkzeuge und Testmöglichkeiten ehrlich.
- Erweitere oder passe Stufen an, wenn technische Abhängigkeiten es erfordern.
- Priorisiere kritische Fehler, Sicherheit und Datenintegrität vor neuen Funktionen.
- Sichere den Projektstand so, dass später nachvollziehbar weitergearbeitet werden kann.
ENDZIEL
Ein möglichst realistischer, stabiler, nachvollziehbar getesteter und gut dokumentierter Airbus A380 für MSFS 2024 mit modularen Flugzeugsystemen, interaktivem Cockpit, integriertem EFB, Variantenplanung, umfangreichen Testphasen, aussagekräftigen Logdateien, systematischen Bugberichten und einer auf die vorhandene Hardware abgestimmten Performance.
Jeder Status muss durch tatsächliche Arbeit oder Nachweise begründet sein. Realitätsnähe, technische Glaubwürdigkeit, reproduzierbare Tests, Schutz bestehender Installationen und ehrliche Dokumentation haben Vorrang vor schnellen oder ungesicherten Erfolgsmeldungen.