Konfiguraationhallinta puolustusohjelmistolle: perustasopisteet, CCB:t ja tarkistuspolut

Ohjelmiston konfiguraationhallinta on kaupallisessa kontekstissa pitkälti synonyymi versionhallinnalle. Puolustushankkeissa versionhallinta on SCM-velvoitteistasi kaikkein vähäisin. Todellinen kurinalaisuus kattaa muodolliset perustasopisteiden luomiset, toimivan muutoksenhallintakomitean, dokumentoidut tekniset muutosehdotukset, konfiguraatiostatuksen kirjanpitoraportit sekä konfiguraatiotarkastukset, joihin hallituksen edustajan on voitava osallistua ja joiden tiedot hänen on voitava varmistaa. Jos jokin näistä elementeistä puuttuu, riskinä ovat sopimuslöydökset, aikatauluviivästykset järjestelmäintegraatiossa sekä epäonnistuneet tarkastukset, jotka pysäyttävät toimitukset. Tämä opas käsittelee jokaista elementtiä järjestyksessä — mitä se tarkoittaa, kuinka se toteutetaan oikein ja missä hankkeet tyypillisesti epäonnistuvat.

Mitä konfiguraationhallinta tarkoittaa puolustushankkeissa

Konfiguraationhallinta puolustuskontekstissa on MIL-STD-973:n ja sen siviiliekvivalenttien (EIA-649, ISO 10007) määrittelemä johtamiskuri. Se kattaa neljä ydintoimintoa: konfiguraation tunnistaminen (mitkä ovat hallitut kohteet ja niiden ominaisuudet?), konfiguraation ohjaus (miten muutoksia arvioidaan ja hyväksytään?), konfiguraatiostatuksen kirjanpito (mikä on kunkin kohteen nykyinen hyväksytty tila?) sekä konfiguraation varmennus ja tarkastus (vastaako tuote hyväksyttyä perustasopistettään?).

Laajuus ulottuu selvästi lähdekoodin ulkopuolelle. Puolustusjärjestelmän konfiguraatioalkioita (CI) ovat laitteistokokoonpanot, piirilevyt, laiteohjelmistokuvat, ohjelmistosuoritettavat tiedostot, tekniset käsikirjat, testausmenettelyt, rajapinnan ohjausasiakirjat sekä tukivälineet. Jokainen CI on virallisesti nimetty yksilöllisellä tunnisteella, vastuullisella suunnitteludisipliinillä ja dokumentoidulla ylätason CI-puuhierarkiasuhteella. Minkä tahansa CI:n ominaisuuksien muuttaminen — suorituskykyspesifikaation, rajapintamäärityksen tai osanumeron muuttaminen — käynnistää konfiguraation ohjaamisprosessin.

Ohjelmistotiimeille käytännön seuraus on, että SCM ei kuulu yksinomaan ohjelmistoryhmälle. Puolustusohjelmistojen ketterät haasteet, jotka aiheutuvat laitteiston ja ohjelmiston samanaikaisesta kehityksestä, ovat pohjimmiltaan konfiguraationhallintaongelma: kun laitteiston CI:t muuttavat rajapintaspesifikaatioitaan, ohjelmiston CI:t on ilmoitettava ja päivitettävä virallisen prosessin kautta eikä ad-hoc-viestiviestillä. Rajapinnan ohjausasiakirja (ICD) on hallittu kohde; sen muuttaminen edellyttää hyväksyttyä teknistä muutosehdotusta ennen toteutuksen aloittamista.

Tämä laajuus selittää, miksi puolustushankkeet ylläpitävät omistautunutta konfiguraationhallintaosastoa (CMO), jonka asiantuntijat vastaavat SCM:stä sen sijaan, että SCM-vastuut annettaisiin kehittäjälle osa-aikaiseksi tehtäväksi. CMO ylläpitää konfiguraationhallinta-tietokantaa, valmistelee ja johtaa CCB:tä, seuraa kaikkia avoimia ECP:ejä ja valmistautuu konfiguraatiotarkastuksiin. Alle 50 hengen hankkeissa CMO voi olla yksi henkilö — mutta sen on oltava henkilö, jolla on omistautunut aika, eikä komitea, jolla ei ole selkeää omistajaa.

Perustasopisteiden tyypit ja elinkaari

MIL-STD-973 määrittelee kolme virallista perustasopistetyyppiä, jotka merkitsevät virstanpylväitä järjestelmän kehityselinkaaren aikana. Jokainen perustasopiste on hyväksytyn teknisen dokumentaation hallittu tilannekuva järjestelmästä tai CI:stä tietyssä hankkeen vaiheessa.

Toiminnallinen perustasopiste. FBL vahvistetaan, kun hallitus hyväksyy järjestelmätason toiminnallisen spesifikaation PDR:ssä. Se tallentaa mitä järjestelmän on tehtävä — suorituskyky-, toiminnallisuus- ja rajapintavaatimukset — määrittelemättä toteutustapaa. Kun se on suljettu, FBL:n muutokset edellyttävät luokan I ECP:tä ja hallituksen hyväksyntää. Ohjelmistotiimit huomaavat FBL-muutokset kipeimmin toiminnallisten konfiguraatiotarkastusten aikana, kun vaatimukset, joista heitä ei ole virallisesti ilmoitettu, ilmestyvät tarkastuksen tarkistuslistaan.

Jaettu perustasopiste. ABL sulkeutuu CDR:ssä ja hallitsee, miten järjestelmätason vaatimukset jaetaan CI:iden kesken. Jokaisen ohjelmisto-CI:n ohjelmistovaatimusspesifikaatio (SRS) jäljittää ABL:ään. Jos järjestelmävaatimus myöhemmin jaetaan uudelleen — esimerkiksi ajoitusvaatimus siirtyy laitteisto-CI:ltä ohjelmisto-CI:lle — tämä uudelleenjako on luokan I muutos, joka edellyttää CCB-hyväksynnän ja SRS:n tarkistamisen ennen kuin ohjelmistotiimi muuttaa yhtäkään koodiriviä. Hankkeet, jotka sallivat epävirallisen uudelleenjaon suunnittelukäytäväkeskusteluissa, päätyvät SRS:ään, joka heijastaa todellista toteutusta eikä hyväksyttyjä vaatimuksia — mikä epäonnistuu FCA:ssa joka kerta.

Tuoteperustasopiste. PBL on kehitysprosessin huipentuma, joka vahvistetaan sen jälkeen kun fyysinen konfiguraatiotarkastus on vahvistanut toimitettavan tuotteen vastaavan dokumentoitua konfiguraatiotaan. PBL sisältää rakennusspesifikaation (tarkka lähdeversio, kääntäjä, työkaluketju ja rakennusparametrit, joita tarvitaan toimitettavan tuotteen jäljentämiseen), ohjelmistoversiokuvauksen ja tosiasiallisen osaluettelon. Kun PBL on vahvistettu, tuote siirtyy ylläpitokonfiguraation hallintaan — kaikki muutokset, olivatpa ne kuinka pieniä tahansa, edellyttävät virallisia ECP:ejä CCB:n kautta.

Muutoksenhallintakomitean rakenne ja toiminta

CCB on päätöksentekoelin, joka arvioi ehdotettuja muutoksia hallittuihin perustasopisteisiin. Se ei ole tarkasteluelin tai tekninen neuvoa-antava ryhmä — se on virallinen viranomainen, jolla on dokumentoitu peruskirja, määritelty jäsenyys ja sitovat äänestyssäännöt. CCB, joka toimii epävirallisesti, tekee päätöksiä ad-hoc-sähköpostiketjuissa eikä virallisissa kokouksissa tallennettuine pöytäkirjoineen, ei ole MIL-STD-973:n mukainen CCB eikä tyydytä hallituksen tarkastusta.

Peruskirja. CCB:n peruskirja on hallittu asiakirja (itsessään SCM:n hallinnoima), joka määrittelee: CCB:n valtuudet ja laajuuden; pysyvät jäsenet ja heidän sijaisensa; päätösvaltaisuusvaatimukset (tyypillisesti äänestäjien enemmistö); äänestyssäännöt rutiinimuutoksille, kiistanalaisille muutoksille ja hätämenettelyille; ECP:n esittämismuodon ja vaaditut tukitiedot; päätösaikataulut (esim. rutiinitoimiset ECP:t päätetään 10 arkipäivän kuluessa esittämisestä); sekä eskalointipolun, kun CCB ei pysty tekemään päätöstä.

Kokoonpano keskikokoisessa hankkeessa. CCB 30–100 hengen puolustusohjelmistohankkeessa sisältää tyypillisesti:

• Puheenjohtaja: Pääinsinööri tai hankepäällikkö — ratkaiseva ääni, varmistaa peruskirjan noudattamisen
• Sihteeri: Konfiguraationhallintajohtaja — valmistelee esityslistat, kirjaa pöytäkirjat, ylläpitää CMDB:tä
• Äänestäjäjäsenet: Järjestelmäsuunnittelun johtaja, ohjelmistojohtaja, laitteistojohtaja, testausjohtaja, ILS/logistiikkaedustaja
• Äänioikeudettomat osallistujat: ECP:n laatija, asianomaiset osa-alueiden johtajat, kustannus- ja aikatauluanalyytikko
• Hallituksen edustaja: COTR tai PM — vaaditaan luokan I muutoksille, voi osallistua tai antaa kirjallisen hyväksynnän

Kokoussykli. Useimmissa hankkeissa pidetään viikoittaisia CCB-kokouksia rutiinimuutoksia varten, vakioesityslistalla, johon kuuluvat: aiemmin hyväksyttyjen ECP:iden tila; uudet ECP:t viime kokouksen jälkeen esitetyt (lyhyt alustava katsaus); täydet esittelyt ja äänestykset päätösvalmisilla ECP:eillä; sekä hätämuutosten ratifioinnit. Hätämuutoksia oikeutetaan CCB:n puheenjohtajan (ja luokan I osalta hallituksen edustajan) toimesta virastaitineen kautta, ja ne ratifioidaan seuraavassa aikataulutetussa CCB-kokouksessa — ratifiointimerkintä sulkee hätäoikeutuksen.

Pöytäkirjat ja asiakirjat. Luonnospöytäkirjat on jaettava 48 tunnin kuluessa kokouksesta ja viimeisteltävä viiden arkipäivän kuluessa. Pöytäkirjat kirjaavat: läsnäolijat, päätösvaltaisuuden tilan, tarkastellut ECP:t päätöksineen ja äänestystuloksineen, toimintakohteet omistajineen ja eräpäivineen sekä kiistanalaisia päätöksiä koskevat eriävät mielipiteet. Pöytäkirjat ovat hallittuja asiakirjoja, jotka arkistoidaan CMDB:hen. CM-sihteerin johdonmukaisuus pöytäkirjojen tuottamisessa ja arkistoinnissa on yksi merkittävimmistä tekijöistä siinä, kuinka valmis hanke on konfiguraatiotarkastukseen.

Tekniset muutosehdotukset: luokka I vs. luokka II

Tekninen muutosehdotus (ECP) on virallinen väline hallittuun perustasopisteeseen kohdistuvien muutosten ehdottamiseksi, arvioimiseksi ja hyväksymiseksi. Jokainen muutos konfiguraatio-ohjattuun kohteeseen, joka vaikuttaa FBL:ään, ABL:ään tai PBL:ään, on dokumentoitava ECP:ssä ennen toteutuksen aloittamista — ei jälkeenpäin.

Luokka I vs. luokka II. Erottelu määrittää, kuka muutoksen hyväksyy ja kuinka paljon prosessia se vaatii:

• Luokka I: Vaikuttaa virallisesti hallittuun perustasopisteeseen, sopimussitoumukseen, hyväksyttyyn rajapintaan (ICD), turvallisuuskriittiseen vaatimukseen tai toimitettavan tuotteen muotoon/sopivuuteen/toimintaan. Vaatii CCB-hyväksynnän ja hallituksen myöntymisen. Toteutus on estetty, kunnes hyväksyntä saadaan. Tyypillisiä esimerkkejä: uuden ominaisuuden lisääminen SRS:ään, ICD-datakentän muuttaminen, turvallisuusvaatimuksen muokkaaminen, testausmenettelyt hyväksytystä testaussuunnitelmasta poistaminen.
• Luokka II: Sisäinen tekninen muutos, joka ei vaikuta mihinkään hallittuun perustasopisteeseen, sopimustoimitettavaan tai hyväksyttyyn rajapintaan. Urakoitsijan sisäinen CCB hyväksyy ilman hankkijan osallistumista. Kirjataan tarkistuspolkua varten, mutta ei hallituksen tarkastelun kohde. Tyypillisiä esimerkkejä: sisäisen moduulirakenteen uudelleenjärjestely, ei-rajapintaisen tietorakenteen muuttaminen, sisäisen koodausstandardin päivittäminen tyylioppaassa, joka ei ole CDRL.

Luokan I ja luokan II välinen raja on usein erimielisyyden lähde. CMP:n on määriteltävä tämä raja käytännön esimerkein. Yleinen sudenkuoppa on insinöörien itsenäinen päättäminen, että heidän muutoksensa on luokan II, vaikka se olisi itse asiassa luokan I — CI-rajan ylittävän viestin sisäisen datamuodon muuttaminen on luokan I muutos, vaikka ulkoinen rajapinta (ICD) näyttäisi muuttumattomalta, koska viestiformaatti on implisiittinen rajapinta.

Vaikutusarviointi. Jokainen ECP vaatii jäsennellyn vaikutusarvioinnin ennen äänestystä. Arviointi kattaa: teknisen riskin (mitä voi mennä pieleen ehdotetussa muutoksessa?); aikatauluvaikutuksen (kuinka monta päivää tämä lisää aikatauluun, mukaan lukien regressiotestaus?); kustannusvaikutuksen (mikä on arvioitu työ- ja materiaalikustannus?); turvallisuusvaikutuksen (vaikuttaako tämä muutos turvallisuuskriittiseen toimintoon tai turvallisuustapauksen oletukseen?); sekä rajapintavaikutuksen (mitkä muut CI:t, jos mitkään, joutuvat tekemään vastaavia muutoksia?). Luokan I muutoksissa vaikutusarvioinnin valmistelevat yhdessä muutoksen laativa insinööri, kustannus- ja aikatauluanalyytikko sekä järjestelmäinsinööri. Muutoksissa, joilla on turvallisuusvaikutus, turvallisuusinsinööri tarkastaa ja allekirjoittaa arvioinnin ennen CCB-esittämistä.

ECP:n elinkaari: laatija valmistelee ECP:n → CM-sihteeri antaa numeron ja kirjaa CMDB:hen → CCB tarkastelee kokouksessa → CCB äänestää (hyväksy / hylkää / lykkää) → hallituksen myöntyminen hankitaan luokan I muutoksille → ECP:n tila päivitetään CMDB:ssä tilaan "Hyväksytty toteutettavaksi" → insinööri toteuttaa muutoksen → versionhallintatoiminto merkitään ECP-numerolla → testitodisteet linkitetään ECP:hen CMDB:ssä → ECP suljetaan. Tämä täydellinen tarkistuspolku — alkuperästä toteutukseen ja testitodisteisiin — on se, mitä hallituksen tarkastajat etsivät FCA:n ja PCA:n aikana. Katso myös oppaastamme SBOM-valvonnasta puolustusputkistoissa, joka liittyy ECP-hallintaan ohjelmistotoimitusketjun muutoksissa.

Ohjelmiston konfiguraationhallinnan työkaluketju

Puolustushankkeen SCM-työkaluketjun on täytettävä kolme rajoitetta, joita kaupallisessa kehityksessä ei sovelleta: työkalujen on oltava hyväksyttäviä hankkeen käyttöoikeuden (ATO) puitteissa; niiden on tuettava MIL-STD-973:n ja soveltuvan lentokelpoisuusstandardin vaatimaa virallista jäljitettävyyttä; sekä — useimmissa puolustushankkeissa — niiden on toimittava ilmaraollisessa tai osittain ilmaraollisessa verkkoympäristössä.

Versionhallinta. Git on de facto -standardi luokittelemattomissa ja luokitelluissa puolustushankkeissa. Luokitelluissa hankkeissa itsehostettuja Git-palvelimia (GitLab Self-Managed, Bitbucket Data Center tai Gitea) käytetään akkreditoidun enklaavin sisällä. Haarautumissuojaussäännöt pakottavat arviointivaatimukset; allekirjoitetut sitoumukset tarjoavat kiistämättömyyden tarkistuspolkua varten. Säilöjen nimeämiskäytännöt ja haarojen nimeämiskäytännöt on dokumentoitava CMP:ssä ja pakotettava palvelinpuolen koukkujen avulla. DO-178C-velvoitteiden hankkeissa versionhallintajärjestelmä on työkalupätevyysehdokas — TQP:n on katettava tietty palvelinversio, konfiguraatio ja perustasopiste-merkintäoperaatio, joka syöttää ohjelmistoversiokuvausta. Laajemman kontekstin saamiseksi CI/CD:n ajamisesta näissä ympäristöissä katso artikkelimme CI/CD ilmaraollisessa puolustuksessa.

Vaatimustenhallinta. IBM Engineering Requirements Management DOORS (klassinen ja uuden sukupolven versio) on edelleen laajimmin käytetty vaatimushallintaväline puolustushankkeissa, erityisesti MIL-STD-973:n ja DO-178C:n hallinnoimissa hankkeissa. Jama Software ja PTC Windchill Requirements ovat yleisiä vaihtoehtoja. Vaatimushallintavälineen on tuettava kaksisuuntaista jäljitettävyyttä (vaatimus → testitapaus → testitulos) ja sen on tuotettava SDP/SCMP:n CDRL:inä vaatimat jäljitettävyysmatriisiartifaktit. Välineen on itsessään toimittava konfiguraation hallinnassa: vaatimustietokanta on konfiguraatioalkio, vaatimusten muutokset välineessä ovat muutossäädeltyjä ja välineen tuotoksen on oltava toistettavissa merkitystä perustasopisteestä.

Konfiguraationhallinta-tietokanta. CMDB seuraa CI:n tilaa, perustasopisteyhdistyksiä, ECP-tietueita, poikkeuslupa/poikkeama-tietueita ja konfiguraatiostatuksen kirjanpitotietoja. Suurissa hankkeissa CMDB on usein IBM Engineering Lifecycle Management (ELM) tai konfiguroitu Jira-instanssi CM-laajennuksella. Pienemmissä hankkeissa käytetään joskus kurinalaisesti Confluence + Jira -yhdistelmää. Mitä valintaa tahansa käytetään, CMDB:n on oltava akkreditoidun rajan sisällä, siinä on oltava käyttöoikeuksien hallinta, joka estää hyväksyttyjen tietueiden luvattoman muokkaamisen, ja sen on tuotettava säännöllinen konfiguraatiostatuksen kirjanpitoraportti, joka on CDRL useimmissa hankkeissa.

Ilmaraollinen SCM-palvelinasetus. Itsehostettu Git-palvelin ja CMDB otetaan käyttöön STIG-kovennetuissa RHEL-instansseissa luokitellun enklaavin sisällä. Ei yhteyttä julkisiin säilöhostauspalveluihin. Palvelinohjelmiston päivitykset noudattavat hankkeen mediansiirtomenettelyä. Palvelimen TLS-sertifikaatit myönnetään hankkeen sisäisestä PKI:stä. Varmuuskopiot tallennetaan enklaavin sisällä salatussa tallennuspalvelussa dokumentoiduilla palautusmenettelyillä. Pääsy versionhallintapalvelimeen on hankkeen käyttöoikeusluettelon hallitsema, ja rooliperusteinen pääsy erottaa luku-, kirjoitus- ja hallintaoikeudet.

Konfiguraatiotarkastukset: FCA ja PCA

Konfiguraatiotarkastukset ovat virallisia katselmuksia, jotka suoritetaan hallituksen osallistuessa tai sen kanssa, tarkoituksena varmistaa, että CI tai järjestelmä täyttää määritellytyiset vaatimuksensa (FCA) ja että tuote on tarkasti dokumentoitu (PCA). Ne eivät ole valinnaisia tarkistuspisteitä — ne ovat sopimusvirstanpylväitä, jotka porttavat toimitukset ja maksut.

Toiminnallinen konfiguraatiotarkastus (FCA). FCA varmistaa, että ohjelmisto-CI on täyttänyt kaikki sille jaetut vaatimukset. Hallituksen tarkastustiimi tarkastelee: hyväksyttyä SRS:ää (ABL-asiakirja), joka näyttää jokaisen vaatimuksen; testausmenettelyjä, jotka testaavat kutakin vaatimusta; testituloksia, jotka osoittavat onnistuneen suorituksen; jäljitettävyysmatriisia, joka linkittää vaatimukset testeihin ja tuloksiin; sekä avoimia eroavuusraportteja, jotka näyttävät kaikki tunnetut poikkeamat ja niiden ratkaisutilan. Yleinen tarkastuslöydös on vaatimukset ilman liitettyjä testejä — "orpovaatimukset", joita suunnittelutiimit aikoivat testata mutta eivät virallisesti kattaneet. Yhtä yleisiä ovat testausmenettelyt, jotka väittävät täyttävänsä vaatimuksen mutta testaavat tosiasiassa jotain sen vieressä olevaa — tarkastajat lukevat testausmenettelyt vaatimustekstiä vastaan kirjaimellisesti. FCA-valmistelu edellyttää jäljitettävyysmatriisin tuottamista vaatimushallintavälineestä 60+ päivää etukäteen, sen tarkastamista puutteiden varalta ja niiden sulkemista tai dokumentointia ennen tarkastusta.

Fyysinen konfiguraatiotarkastus (PCA). PCA varmistaa, että toimitettava tai käyttöön otettava tuote vastaa täsmälleen dokumentoitua konfiguraatiotaan. Ydinesittely on rakennuksen toistettavuus: urakoitsijan on osoitettava, että ohjelmistoversiokuvauksessa tunnistetusta hallitusta lähdeperustasopisteestä lähtien he voivat toistaa binäärin, joka on tavu tavulta identtinen toimitettavan kanssa. Tämä edellyttää täydellistä rakennusympäristöspesifikaatiota — ei vain kääntäjäversiota, vaan jokaista rakennusketjun työkalua, jokaista rakennuslippua, jokaista ympäristömuuttujaa, joka vaikuttaa tuotokseen. Hankkeet, jotka käyttävät dokumentoimattomia rakennusympäristöriippuvuuksia, löytävät tämän ongelman PCA:ssa; ratkaisu on ylläpitää rakennusympäristöä konfiguraatio-ohjattuna kontti-imagena, jonka tarkka sisältö on osa PBL-dokumentaatiota.

# 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-valmistelun tarkistuslistan kohteet: varmista, että SVD:tä vastaava versionhallintatunniste on olemassa ja allekirjoitettu; tuota osaluettelo CMDB:stä ja vertaa sitä rakennusympäristön tosiasialliseen pakettijoukkoon; varmista, että kaikki hyväksytyt poikkeusluvat ja poikkeamat ovat dokumentoituja ja allekirjoitettuja; sekä varmista, että avoimen asian lista vastaa SVD:n tunnettujen poikkeamien osiota. Mikä tahansa ristiriita CMDB:n tietueen ja fyysisen tuotteen välillä on tarkastuslöydös, joka on ratkaistava ennen kuin PCA voidaan sulkea.

MIL-STD-973:n ja DO-178C:n integrointi

Hankkeiden, jotka tuottavat lentoonkelpoista ohjelmistoa, on täytettävä sekä MIL-STD-973 (puolustushankkinnan SCM-standardi) että DO-178C:n osio 7 (ohjelmiston konfiguraationhallinta lentoonkelpoisen ohjelmiston sertifioinnille). Nämä kaksi ovat toisiaan täydentäviä, mutta niillä on erilaiset painotukset ja toimitettavat asiakirjat.

Konfiguraationhallintasuunnitelma vs. ohjelmiston konfiguraationhallintasuunnitelma. MIL-STD-973 edellyttää järjestelmätason CMP:tä CDRL:nä. DO-178C edellyttää erillistä ohjelmiston konfiguraationhallintasuunnitelmaa (SCMP) ohjelmiston elinkaaren data-kohteena. SCMP:n on kuvattava, miten kaikki ohjelmiston elinkaaren data (SLCD) asetetaan konfiguraation hallintaan, miten muutoksia hallitaan, miten perustasopisteet vahvistetaan ja miten ongelmienraportointi- ja muutoksenhallintaprosessi toimii. SCMP:n tarkastelee DER (nimetty suunnittelunedustaja) tai sertifiointiviranomainen osana ohjelmiston suunnittelukatselmusta. Järjestelmätason CMP:n ja SCMP:n on oltava johdonmukaisia ja ristiin viittaavia, mutta ne ovat erillisiä asiakirjoja, joilla on erilliset kohderyhmät.

Konfiguraationhallintaan liittyvät CDRL:t. Tyypillisen puolustushankkeen CM-liittyvät CDRL:t sisältävät:

• DI-CMAN-80858A — Konfiguraationhallintasuunnitelma: SCM-pääprosessiasiakirja
• DI-CMAN-81259 — Konfiguraatiostatuksen kirjanpitoraportti: Säännöllinen CI-tilayhteenveto
• DI-CMAN-81000 — Tekninen muutosehdotus: Muutoskohtainen toimitettava
• DI-MCCR-80013A — Ohjelmistoversiokuvaus: Julkaisukohtainen toimitettava
• DI-CMAN-81121 — Rajapinnan ohjausasiakirja: Rajapintakohtainen toimitettava

Työkalupätevyys SCM-työkaluille. DO-178C ja sen seuranaisstandardi DO-330 edellyttävät, että kehitystyökalut — työkalut, joiden tuotos tulee osaksi lentoonkelpoista ohjelmistoa tai joiden epäonnistuminen voi tuoda havaitsemattomia virheitä — pätevöidään. Versionhallintajärjestelmä, jonka merkitty perustasopiste syöttää SVD-toimitettavaa, on ehdokas TD3-pätevöintiin DO-330:n mukaan. Pätevöintitodisteet sisältävät työkalutoimintavaatimukset (TOR), työkalupätevöintisuunnitelman, testitietueet, jotka osoittavat työkalun oikein tallentavan ja palauttavan tarkan binäärisisällön, sekä ongelmaraporttiprosessin itse työkalulle. Hankkeet löytävät tämän vaatimuksen myöhään, sen jälkeen kun ne ovat jo valinneet ja ottaneet käyttöön versionhallintapalvelimensa, koska DO-178C:n vaatimus luetaan usein vain kääntäjiä ja koodingeneraattoreita koskevaksi. SCM-työkalun työkalupätevöintisuunnitelman aloittaminen samaan aikaan kuin SCMP — ohjelmiston suunnittelun aikana — estää viime hetken pätevöintikiireen, joka viivästyttää sertifiointia.

Ongelmienraportointi ja muutoksenhallinta. DO-178C:n osio 7.3 edellyttää dokumentoitua ongelmienraportointiprosessia kaikelle CM-hallinnassa olevalle ohjelmiston elinkaaren datalle. Jokainen poikkeama — ei vain koodivirheet, vaan myös virheet vaatimuksissa, testausmenettelyissä, suunnitteluasiakirjoissa ja analyysilaporteissa — on syötettävä ongelmaraporttijärjestelmään ja seurattava sulkemiseen. Ongelmaraporttitiedot syöttävät FCA:ta (näyttäen avoimet poikkeamat ja niiden ratkaisu) ja PCA:ta (näyttäen, että SVD:n tunnettu poikkeamaluettelo on tarkka ja täydellinen). Ongelmaraporttijärjestelmän integrointi ECP-työnkulkuun varmistaa, että perustasopistemuutosta vaativat ongelmat tuottavat ECP:n automaattisesti eikä niitä jää elämään erilliseen vikatunnistimeen, jota tarkastajat eivät pysty yhdistämään hallittuun perustasopisteeseen.

Hankkeet, jotka investoivat tähän integrointiin — vaatimushallintaväline, joka syöttää jäljitettävyyttä testinhallintavälineelle, joka syöttää tuloksia CMDB:hen, joka linkittyy ECP-työnkulkuun — omaavat todistettavasti lyhyemmät FCA- ja PCA-syklit sekä vähemmän tarkastuksen jälkeisiä löydöksiä kuin hankkeet, jotka hallitsevat näitä tietueita erillisistä laskentataulukoista. Investointi on merkittävä, mutta vaihtoehto — tarkastusaineiston rekonstruoiminen aikapaineen alla hallituksen edustajien odottaessa — on kalliimpaa ja hankkeiden suhteiden kannalta vahingollisempaa.