Konfigurationsmanagement für Verteidigungssoftware: Baselines, CCBs und Audit-Trails

Software-Konfigurationsmanagement bedeutet im kommerziellen Umfeld weitgehend dasselbe wie Versionskontrolle. In Verteidigungsprogrammen ist die Versionskontrolle die geringste SCM-Verpflichtung. Die eigentliche Disziplin umfasst die formale Baseline-Etablierung, ein funktionierendes Change Control Board, dokumentierte Engineering Change Proposals, Configuration Status Accounting Reports und Konfigurationsaudits, in die ein Regierungsvertreter hineingehen und alles überprüfen können muss. Wer auch nur eines dieser Elemente auslässt, riskiert Vertragsbefunde, Terminverzögerungen bei der Systemintegration und gescheiterte Audits, die Lieferungen blockieren. Dieser Leitfaden behandelt jedes Element der Reihe nach — was es bedeutet, wie man es korrekt umsetzt und wo Programme typischerweise scheitern.

Was Konfigurationsmanagement in Verteidigungsprogrammen bedeutet

Konfigurationsmanagement im Verteidigungskontext ist eine durch MIL-STD-973 und seine zivilen Äquivalente (EIA-649, ISO 10007) definierte Managementdisziplin. Sie umfasst vier Kernfunktionen: Konfigurationsidentifikation (welche Elemente werden kontrolliert und welche Attribute haben sie?), Konfigurationskontrolle (wie werden Änderungen bewertet und genehmigt?), Configuration Status Accounting (was ist der aktuelle genehmigte Zustand jedes Elements?) und Konfigurationsverifikation und -audit (entspricht das Produkt seiner genehmigten Baseline?).

Der Geltungsbereich geht weit über den Quellcode hinaus. Zu den Konfigurationselementen (CIs) eines Verteidigungssystems gehören Hardware-Baugruppen, Leiterplatten, Firmware-Images, Software-Executables, technische Handbücher, Testverfahren, Interface Control Documents und sogar Unterstützungsausrüstung. Jedes CI wird formal mit einer eindeutigen Kennung, einer verantwortlichen Ingenieursdisziplin und einer dokumentierten Eltern-Kind-Beziehung zum CI-Baum auf Systemebene erfasst. Jede Änderung der Attribute eines CI — seiner Leistungsspezifikation, seiner Schnittstellendefinition, seiner Teilenummer — löst den Konfigurationskontrollprozess aus.

Für Software-Teams bedeutet dies in der Praxis, dass SCM nicht allein in der Verantwortung der Software-Gruppe liegt. Die agilen Herausforderungen in der Verteidigungssoftware, die aus der gleichzeitigen Hardware- und Softwareentwicklung entstehen, sind grundlegend ein Konfigurationsmanagementproblem: Wenn Hardware-CIs ihre Schnittstellenspezifikationen ändern, müssen Software-CIs über einen formalen Prozess benachrichtigt und aktualisiert werden — nicht über eine informelle Nachricht. Das Interface Control Document (ICD) ist ein kontrolliertes Element; Änderungen daran erfordern einen genehmigten Engineering Change Proposal, bevor mit der Implementierung begonnen wird.

Diese Breite ist der Grund, warum Verteidigungsprogramme ein dediziertes Configuration Management Office (CMO) mit Spezialisten unterhalten, anstatt SCM-Verantwortlichkeiten einem Entwickler als Nebenaufgabe zuzuweisen. Das CMO pflegt die Configuration Management Database, bereitet den CCB vor und leitet ihn, verfolgt alle offenen ECPs und bereitet Konfigurationsaudits vor. Bei Programmen mit weniger als 50 Mitarbeitern kann das CMO eine einzelne Person sein — aber es muss eine Person sein, mit dedizierter Zeit, nicht ein Ausschuss ohne klaren Verantwortlichen.

Baseline-Typen und ihr Lebenszyklus

MIL-STD-973 definiert drei formale Baseline-Typen, die Meilensteine im Systementwicklungslebenszyklus markieren. Jede Baseline ist ein kontrollierter Snapshot der genehmigten technischen Dokumentation für das System oder ein CI zu einem definierten Zeitpunkt im Programm.

Functional Baseline. Die FBL wird etabliert, wenn die Regierung die funktionale Systemspezifikation beim PDR akzeptiert. Sie erfasst, was das System leisten muss — Leistungs-, Funktions- und Schnittstellenanforderungen — ohne festzulegen, wie. Nach dem Abschluss erfordern Änderungen an der FBL einen Klasse-I-ECP und die Zustimmung der Regierung. Software-Teams entdecken FBL-Änderungen am schmerzhaftesten bei Functional Configuration Audits, wenn Anforderungen, über die sie nie formal benachrichtigt wurden, auf der Audit-Checkliste erscheinen.

Allocated Baseline. Die ABL schließt beim CDR und kontrolliert, wie Anforderungen auf Systemebene auf CIs verteilt werden. Die Software Requirements Specification (SRS) jedes Software-CI verweist auf die ABL. Wenn eine Systemanforderung nachträglich neu zugewiesen wird — etwa eine Timing-Anforderung von einem Hardware-CI auf ein Software-CI verlagert wird — ist diese Neuzuweisung eine Klasse-I-Änderung, die eine CCB-Genehmigung und eine SRS-Revision erfordert, bevor das Software-Team auch nur eine einzige Codezeile ändert. Programme, die informelle Neuzuweisungen in Flurgesprächen zulassen, enden mit einer SRS, die die tatsächliche Implementierung widerspiegelt und nicht die genehmigten Anforderungen — und das scheitert beim FCA jedes Mal.

Product Baseline. Die PBL ist der Höhepunkt des Entwicklungsprozesses und wird nach dem Physical Configuration Audit etabliert, der bestätigt, dass das gelieferte Produkt seiner dokumentierten Konfiguration entspricht. Die PBL enthält die Build-Spezifikation (genaue Quellversion, Compiler, Tool-Chain und Build-Parameter, die benötigt werden, um das Lieferobjekt zu reproduzieren), die Software Version Description und die als-gebaute Stückliste. Sobald die PBL etabliert ist, tritt das Produkt in die Sustainment-Konfigurationskontrolle ein — alle Änderungen, so klein sie auch sein mögen, erfordern formale ECPs durch den CCB.

Change Control Board: Struktur und Betrieb

Der CCB ist das Entscheidungsgremium, das vorgeschlagene Änderungen an kontrollierten Baselines bewertet. Es ist kein Review-Board oder eine technische Beratungsgruppe — es ist eine formale Autorität mit dokumentierter Charta, definierter Mitgliedschaft und verbindlichen Abstimmungsregeln. Ein CCB, der informell operiert, der Entscheidungen in Ad-hoc-E-Mail-Threads statt in formalen Sitzungen mit aufgezeichneten Protokollen trifft, ist kein CCB im Sinne von MIL-STD-973 und wird ein Regierungsaudit nicht bestehen.

Charta. Die CCB-Charta ist ein kontrolliertes Dokument (selbst unter SCM verwaltet), das definiert: die Autorität und den Geltungsbereich des CCB; ständige Mitgliedschaft und Vertreter; Quorumanforderungen (in der Regel die Mehrheit der stimmberechtigten Mitglieder); Abstimmungsregeln für Routineänderungen, strittige Änderungen und Notfallverfahren; das ECP-Einreichungsformat und erforderliche Begleitinformationen; Entscheidungsfristen (z. B. Routine-ECPs werden innerhalb von 10 Werktagen nach Einreichung entschieden); und den Eskalationspfad, wenn der CCB keine Entscheidung treffen kann.

Zusammensetzung für ein mittelgroßes Programm. Ein CCB für ein Verteidigungssoftwareprogramm mit 30 bis 100 Mitarbeitern umfasst typischerweise:

• Vorsitzender: Chefingenieur oder Programmmanager — Stichentscheid, stellt die Einhaltung der Charta sicher
• Sekretär: Configuration Management Officer — bereitet Tagesordnungen vor, führt Protokoll, pflegt CMDB
• Stimmberechtigte Mitglieder: Leitung Systems Engineering, Software-Leitung, Hardware-Leitung, Test-Leitung, ILS/Logistik-Vertreter
• Nicht stimmberechtigte Teilnehmer: ECP-Ersteller, betroffene Subsystem-Leitungen, Kosten-/Terminanalyst
• Regierungsvertreter: COTR oder PM — erforderlich für Klasse-I-Änderungen, kann anwesend sein oder schriftliche Zustimmung erteilen

Sitzungsrhythmus. Die meisten Programme führen wöchentliche CCB-Sitzungen für Routineänderungen durch, mit einer festen Tagesordnung, die umfasst: Status zuvor genehmigter ECPs; neue ECPs, die seit der letzten Sitzung eingereicht wurden (kurze Erstprüfung); vollständige Präsentationen und Abstimmungen über ECPs, die zur Entscheidung bereit sind; sowie Ratifizierungen von Notfalländerungen. Notfalländerungen werden außerhalb des Rhythmus vom CCB-Vorsitzenden (und dem Regierungsvertreter für Klasse I) autorisiert und auf der nächsten planmäßigen CCB-Sitzung ratifiziert — der Ratifizierungsnachweis schließt die Notfallgenehmigung ab.

Protokolle und Aufzeichnungen. Entwurfsprotokolle müssen innerhalb von 48 Stunden nach der Sitzung verteilt und innerhalb von fünf Werktagen abgeschlossen werden. Protokolle halten fest: Teilnehmer, Quorumstatus, geprüfte ECPs mit Entscheidung und Abstimmungsergebnissen, Maßnahmenpunkte mit Verantwortlichen und Fälligkeitsterminen sowie abweichende Meinungen zu strittigen Entscheidungen. Protokolle sind kontrollierte Dokumente, die in der CMDB abgelegt werden. Die Konsequenz des CM-Sekretärs bei der Erstellung und Ablage von Protokollen ist einer der bedeutendsten Faktoren für die Audit-Bereitschaft eines Programms.

Engineering Change Proposals: Klasse I vs. Klasse II

Ein Engineering Change Proposal (ECP) ist das formale Instrument zur Beantragung, Bewertung und Genehmigung von Änderungen an einer kontrollierten Baseline. Jede Änderung an einem konfigurationskontrollierten Element, die die FBL, ABL oder PBL beeinflussen würde, muss in einem ECP dokumentiert werden, bevor mit der Implementierung begonnen wird — nicht danach.

Klasse I vs. Klasse II. Die Unterscheidung bestimmt, wer die Änderung genehmigt und wie viel Prozess erforderlich ist:

• Klasse I: Betrifft eine formal kontrollierte Baseline, eine vertragliche Verpflichtung, eine genehmigte Schnittstelle (ICD), eine sicherheitskritische Anforderung oder Form/Fit/Funktion eines Lieferobjekts. Erfordert CCB-Genehmigung plus Zustimmung der Regierung. Die Implementierung ist blockiert, bis die Genehmigung vorliegt. Typische Beispiele: Hinzufügen einer neuen Fähigkeit zur SRS, Änderung eines ICD-Datenfeldes, Änderung einer Sicherheitsanforderung, Streichung eines Testverfahrens aus dem genehmigten Testplan.
• Klasse II: Interne technische Änderung, die keine kontrollierte Baseline, kein vertragliches Lieferobjekt und keine genehmigte Schnittstelle berührt. Wird vom internen CCB des Auftragnehmers ohne Beteiligung des Auftraggebers genehmigt. Wird für den Audit-Trail aufgezeichnet, unterliegt aber keiner Regierungsprüfung. Typische Beispiele: Refactoring interner Modulstrukturen, Änderung einer nicht schnittstellenrelevanten Datenstruktur, Aktualisierung interner Codierungsstandards in einem Style Guide, der kein CDRL ist.

Die Grenze zwischen Klasse I und Klasse II ist häufig Gegenstand von Meinungsverschiedenheiten. Der CMP muss diese Grenze mit ausgearbeiteten Beispielen definieren. Ein häufiger Fehler ist, dass Ingenieure eigenständig entscheiden, ihre Änderung sei Klasse II, obwohl sie tatsächlich Klasse I ist — die Änderung des internen Datenformats einer Nachricht, die eine CI-Grenze überschreitet, ist eine Klasse-I-Änderung, auch wenn die externe Schnittstelle (das ICD) scheinbar unverändert bleibt, weil das Nachrichtenformat eine implizite Schnittstelle darstellt.

Folgenabschätzung. Jeder ECP erfordert eine strukturierte Folgenabschätzung, bevor er zur Abstimmung gestellt werden kann. Die Abschätzung umfasst: technisches Risiko (was kann bei der vorgeschlagenen Änderung schiefgehen?); Terminauswirkung (wie viele Tage kommt der Terminplan hinzu, einschließlich Regressionstests?); Kostenauswirkung (wie hoch sind die geschätzten Arbeits- und Materialkosten?); Sicherheitsauswirkung (berührt diese Änderung eine sicherheitskritische Funktion oder eine Annahme des Safety Case?); und Schnittstellenauswirkung (welche anderen CIs müssen entsprechende Änderungen vornehmen?). Für Klasse-I-Änderungen wird die Folgenabschätzung gemeinsam vom entwerfenden Ingenieur, dem Kosten-/Terminanalyst und dem Systems Engineer erstellt. Bei Änderungen mit Sicherheitsauswirkungen prüft und unterzeichnet der Sicherheitsingenieur die Abschätzung vor der CCB-Einreichung.

Der ECP-Lebenszyklus: Ersteller entwirft ECP → CM-Sekretär vergibt Nummer und protokolliert in CMDB → CCB prüft in der Sitzung → CCB stimmt ab (genehmigen / ablehnen / zurückstellen) → Zustimmung der Regierung für Klasse I eingeholt → ECP-Status in CMDB auf „Genehmigt zur Implementierung" aktualisiert → Ingenieur implementiert Änderung → Versionskontroll-Commit mit ECP-Nummer getaggt → Testnachweis mit ECP in CMDB verknüpft → ECP geschlossen. Dieser vollständige Audit-Trail — von der Erstellung über die Implementierung bis zum Testnachweis — ist das, worauf Regierungsprüfer bei FCA und PCA achten. Siehe auch unseren Leitfaden zur SBOM-Durchsetzung in Verteidigungspipelines, die sich mit dem ECP-Management für Änderungen in der Software-Lieferkette überschneidet.

Software-Konfigurationsmanagement-Toolchain

Die SCM-Toolchain für ein Verteidigungsprogramm muss drei Einschränkungen genügen, die in der kommerziellen Entwicklung nicht gelten: Die Tools müssen unter der Authority to Operate (ATO) des Programms genehmigungsfähig sein; sie müssen die formale Rückverfolgbarkeit unterstützen, die MIL-STD-973 und etwaige geltende Lufttüchtigkeitsstandards erfordern; und — für die meisten Verteidigungsprogramme — müssen sie in einer air-gapped oder teilweise air-gapped Netzwerkumgebung betrieben werden können.

Versionskontrolle. Git ist der De-facto-Standard in nicht klassifizierten und klassifizierten Verteidigungsprogrammen. Für klassifizierte Programme werden selbst gehostete Git-Server (GitLab Self-Managed, Bitbucket Data Center oder Gitea) innerhalb der akkreditierten Enklave eingesetzt. Branch-Protection-Regeln erzwingen Review-Anforderungen; signierte Commits liefern Nichtabstreitbarkeit für den Audit-Trail. Namenskonventionen für Repositories und Branches sollten im CMP dokumentiert und über serverseitige Hooks durchgesetzt werden. Für Programme mit DO-178C-Verpflichtungen ist das Versionskontrollsystem ein Tool-Qualification-Kandidat — der TQP muss die spezifische Serverversion, die Konfiguration und den Baseline-Label-Vorgang abdecken, der die Software Version Description speist. Für den breiteren Kontext des Betriebs von CI/CD in diesen Umgebungen siehe unseren Artikel zu CI/CD für air-gapped Verteidigungsumgebungen.

Anforderungsmanagement. IBM Engineering Requirements Management DOORS (Classic und Next Generation) bleibt das am weitesten verbreitete Anforderungstool in Verteidigungsprogrammen, insbesondere solchen, die durch MIL-STD-973 und DO-178C geregelt werden. Jama Software und PTC Windchill Requirements sind gängige Alternativen. Das Anforderungstool muss bidirektionale Rückverfolgbarkeit (Anforderung → Testfall → Testergebnis) unterstützen und muss die Rückverfolgbarkeitsmatrix-Artefakte erzeugen können, die SDP/SCMP als CDRLs erfordern. Das Tool muss selbst unter Konfigurationskontrolle betrieben werden: Die Anforderungsdatenbank ist ein Konfigurationselement, Änderungen an Anforderungen im Tool werden konfigurationskontrolliert, und der Output des Tools muss aus einer beschrifteten Baseline reproduzierbar sein.

Configuration Management Database. Die CMDB verfolgt CI-Status, Baseline-Zuordnungen, ECP-Einträge, Waiver-/Deviation-Einträge und Configuration Status Accounting-Daten. In großen Programmen ist die CMDB oft IBM Engineering Lifecycle Management (ELM) oder eine konfigurierte Jira-Instanz mit einem CM-Plugin. Kleinere Programme verwenden manchmal eine strukturierte Kombination aus Confluence und Jira. Unabhängig von der Wahl muss die CMDB innerhalb der akkreditierten Grenze liegen, Zugriffskontrollen haben, die nicht autorisierte Änderungen an genehmigten Einträgen verhindern, und den periodischen Configuration Status Accounting Report erzeugen können, der in den meisten Programmen ein CDRL ist.

Air-gapped SCM-Server-Einrichtung. Der selbst gehostete Git-Server und die CMDB werden auf STIG-gehärteten RHEL-Instanzen innerhalb der klassifizierten Enklave bereitgestellt. Keine Verbindung zu öffentlichen Repository-Hosting-Diensten. Paketaktualisierungen der Server-Software folgen dem Medienübertragungsverfahren des Programms. Die TLS-Zertifikate des Servers werden von der internen PKI des Programms ausgestellt. Backups werden in der Enklave mit verschlüsseltem Speicher und dokumentierten Wiederherstellungsverfahren gespeichert. Der Zugriff auf den Versionskontrollserver wird durch die Zugriffskontrollliste des Programms geregelt, mit rollenbasierten Berechtigungen, die Lese-, Schreib- und Administratorzugriff trennen.

Konfigurationsaudits: FCA und PCA

Konfigurationsaudits sind formale Prüfungen, die von der Regierung oder unter ihrer Beteiligung durchgeführt werden, um zu verifizieren, dass ein CI oder System seine spezifizierten Anforderungen erfüllt (FCA) und dass das Produkt korrekt dokumentiert ist (PCA). Sie sind keine optionalen Checkpoints — sie sind Vertragsmeilensteine, die Lieferungen und Zahlungen freigeben.

Functional Configuration Audit (FCA). Der FCA verifiziert, dass das Software-CI alle ihm zugewiesenen Anforderungen erfüllt hat. Das Regierungs-Auditteam prüft: die genehmigte SRS (ABL-Dokument), die jede Anforderung zeigt; die Testverfahren, die jede Anforderung testen; die Testergebnisse, die erfolgreiche Ausführung belegen; die Rückverfolgbarkeitsmatrix, die Anforderungen mit Tests und Ergebnissen verknüpft; und die offenen Mängellisten, die alle bekannten Anomalien und ihren Lösungsstatus zeigen. Ein häufiger Auditbefund sind Anforderungen ohne zugehörigen Test — „verwaiste Anforderungen", die Engineering-Teams zu testen beabsichtigten, aber nicht formal abgedeckt haben. Ebenso häufig sind Testverfahren, die behaupten, eine Anforderung zu erfüllen, aber tatsächlich etwas Benachbartes testen — Auditoren lesen Testverfahren buchstäblich gegen den Anforderungstext. Die FCA-Vorbereitung erfordert, dass die Rückverfolgbarkeitsmatrix aus dem Anforderungstool mindestens 60 Tage im Voraus generiert, auf Lücken überprüft und diese Lücken vor dem Audit geschlossen oder dokumentiert werden.

Physical Configuration Audit (PCA). Der PCA verifiziert, dass das zu liefernde oder einzusetzende Produkt exakt seiner dokumentierten Konfiguration entspricht. Die Kerndemonstration ist die Build-Reproduzierbarkeit: Der Auftragnehmer muss zeigen, dass er, ausgehend von der in der Software Version Description angegebenen kontrollierten Quellbaseline, ein Binary reproduzieren kann, das byteweise identisch mit dem Lieferobjekt ist. Dies erfordert eine vollständige Build-Umgebungsspezifikation — nicht nur die Compiler-Version, sondern jedes Tool in der Build-Chain, jedes Build-Flag, jede Umgebungsvariable, die den Output beeinflusst. Programme, die undokumentierte Build-Umgebungsabhängigkeiten verwenden, entdecken dieses Problem beim PCA; die Lösung besteht darin, die Build-Umgebung als konfigurationskontrolliertes Container-Image zu pflegen, dessen genaue Inhalte Teil der PBL-Dokumentation sind.

# Build environment specification — PBL artifact
build_environment:
  base_image: rhel9.4-build:2026.06.15
  compiler:   gcc-13.3.1
  linker:     binutils-2.41
  make:       gnu-make-4.4.1
  java:       openjdk-21.0.3
  maven:      apache-maven-3.9.8
  flags:
    CFLAGS:   "-O2 -fstack-protector-strong -D_FORTIFY_SOURCE=2"
    LDFLAGS:  "-Wl,-z,relro,-z,now"

# Baseline label (tagged in version control)
source_baseline:  csci-001-v3.2.1
svd_revision:     D

# Verification hash (SHA-256 of deliverable binary)
deliverable_hash: e3b4c7a1f9d25843...  
            

PCA-Vorbereitungs-Checkliste: Prüfen, ob das Versionskontroll-Tag, das der SVD entspricht, vorhanden und signiert ist; die Stückliste aus der CMDB generieren und mit dem tatsächlichen Paketbestand in der Build-Umgebung vergleichen; sicherstellen, dass alle genehmigten Waiver und Deviations dokumentiert und unterzeichnet sind; und bestätigen, dass die offene Mängelliste mit dem Abschnitt zu bekannten Anomalien in der SVD übereinstimmt. Jede Diskrepanz zwischen dem CMDB-Eintrag und dem physischen Produkt ist ein Auditbefund, der vor dem Abschluss des PCA behoben werden muss.

Integration von MIL-STD-973 und DO-178C

Programme, die Luftfahrtsoftware produzieren, müssen sowohl MIL-STD-973 (den Verteidigungsbeschaffungs-SCM-Standard) als auch DO-178C Abschnitt 7 (Software Configuration Management für die Zertifizierung von Luftfahrtsoftware) erfüllen. Die beiden sind komplementär, haben aber unterschiedliche Schwerpunkte und Lieferobjekte.

Configuration Management Plan vs. Software Configuration Management Plan. MIL-STD-973 erfordert einen systemweiten CMP als CDRL. DO-178C erfordert einen separaten Software Configuration Management Plan (SCMP) als Software Life Cycle Data-Element. Der SCMP muss beschreiben, wie alle Software Life Cycle Data (SLCD) unter Konfigurationskontrolle gestellt werden, wie Änderungen verwaltet werden, wie Baselines etabliert werden und wie der Prozess zur Problemmeldung und Änderungskontrolle funktioniert. Der SCMP wird vom DER (Designated Engineering Representative) oder der Zertifizierungsbehörde im Rahmen der Software-Planungsprüfung geprüft. Der systemweite CMP und der SCMP sollten konsistent und wechselseitig referenzierend sein, sind jedoch eigenständige Dokumente mit unterschiedlichen Zielgruppen.

CDRLs für das Konfigurationsmanagement. Die CM-bezogenen CDRLs eines typischen Verteidigungsprogramms umfassen:

• DI-CMAN-80858A — Configuration Management Plan: Übergeordnetes SCM-Prozessdokument
• DI-CMAN-81259 — Configuration Status Accounting Report: Periodische CI-Statusübersicht
• DI-CMAN-81000 — Engineering Change Proposal: Änderungsbezogenes Lieferobjekt
• DI-MCCR-80013A — Software Version Description: Versions-Lieferobjekt
• DI-CMAN-81121 — Interface Control Document: Schnittstellenbezogenes Lieferobjekt

Tool-Qualifikation für SCM-Tools. DO-178C und der begleitende Standard DO-330 fordern, dass Development Tools — Tools, deren Output Teil der Luftfahrtsoftware wird oder deren Ausfall unerkannte Fehler einführen könnte — qualifiziert werden. Ein Versionskontrollsystem, dessen beschriftete Baseline in das SVD-Lieferobjekt einfließt, ist ein Kandidat für die TD3-Qualifikation nach DO-330. Qualifikationsnachweise umfassen Tool Operational Requirements (TOR), einen Tool Qualification Plan, Testaufzeichnungen, die belegen, dass das Tool binären Inhalt korrekt speichert und abruft, sowie einen Problemmeldungsprozess für das Tool selbst. Programme entdecken diese Anforderung spät, nachdem sie ihren Versionskontrollserver bereits ausgewählt und eingesetzt haben, weil die DO-178C-Anforderung oft nur als auf Compiler und Code-Generatoren anwendbar gelesen wird. Den Tool Qualification Plan für das SCM-Tool gleichzeitig mit dem SCMP zu starten — während der Software-Planung — verhindert das Last-Minute-Qualifikations-Chaos, das die Zertifizierung verzögert.

Problemmeldung und Änderungskontrolle. DO-178C Abschnitt 7.3 erfordert einen dokumentierten Problemmeldungsprozess für alle Software Life Cycle Data unter CM-Kontrolle. Jede Anomalie — nicht nur Code-Fehler, sondern auch Fehler in Anforderungen, Testverfahren, Entwurfsdokumenten und Analysebericht — muss im Problemmeldungssystem eingetragen und bis zum Abschluss verfolgt werden. Die Problemmeldungsdaten fließen in den FCA (zeigen offene Anomalien und ihre Disposition) und den PCA (zeigen, dass die bekannte Anomalienliste in der SVD korrekt und vollständig ist) ein. Die Integration des Problemmeldungssystems in den ECP-Workflow stellt sicher, dass Probleme, die eine Baseline-Änderung erfordern, automatisch einen ECP erzeugen, anstatt in einem separaten Defect-Tracker zu leben, den Auditoren nicht mit der kontrollierten Baseline korrelieren können.

Programme, die in diese Integration investieren — ein Anforderungstool, das Rückverfolgbarkeit zu einem Test-Management-Tool liefert, das Ergebnisse an eine CMDB liefert, die mit dem ECP-Workflow verknüpft ist — haben nachweislich kürzere FCA- und PCA-Zyklen und weniger Post-Audit-Befunde als Programme, die diese Aufzeichnungen in unzusammenhängenden Tabellenkalkulationen verwalten. Die Investition ist erheblich, aber die Alternative — Audit-Nachweise unter Zeitdruck zu rekonstruieren, während Regierungsvertreter warten — ist teurer und schadet den Programmbeziehungen stärker.