Управління конфігурацією програмного забезпечення в оборонних програмах: базові лінії, CCB та журнали аудиту

У комерційному контексті управління конфігурацією програмного забезпечення здебільшого зводиться до контролю версій. В оборонних програмах контроль версій — лише мінімальна частина зобов'язань SCM. Справжня дисципліна охоплює формальне встановлення базових ліній, функціонуючу раду з контролю змін, задокументовані пропозиції щодо інженерних змін, звіти про статус конфігурації та аудити конфігурації, які представник замовника може перевірити в будь-який момент. Пропуск будь-якого з цих елементів загрожує контрактними зауваженнями, затримками за розкладом під час системної інтеграції та провальними аудитами, що блокують постачання. Цей матеріал послідовно розкриває кожен елемент: що він означає, як правильно його реалізувати і де програми зазвичай помиляються.

Що означає управління конфігурацією в оборонних програмах

Управління конфігурацією в оборонному контексті — це управлінська дисципліна, визначена MIL-STD-973 та її цивільними аналогами (EIA-649, ISO 10007). Вона охоплює чотири основні функції: ідентифікація конфігурації (які елементи контролюються та які їх атрибути?), контроль конфігурації (як оцінюються та затверджуються зміни?), облік статусу конфігурації (який поточний затверджений стан кожного елемента?) та верифікація і аудит конфігурації (чи відповідає продукт затвердженій базовій лінії?).

Сфера охоплення виходить далеко за межі вихідного коду. Елементи конфігурації (CI) оборонної системи включають апаратні вузли, друковані плати, образи мікропрограмного забезпечення, програмні виконувані файли, технічні посібники, процедури випробувань, документи контролю інтерфейсів і навіть допоміжне обладнання. Кожен CI офіційно призначається унікальним ідентифікатором, відповідальною інженерною дисципліною та задокументованим відношенням батько-нащадок у дереві CI системного рівня. Зміна будь-якого атрибута CI — специфікації продуктивності, визначення інтерфейсу, номера деталі — запускає процес контролю конфігурації.

Для команд розробників ПЗ практичний наслідок полягає в тому, що SCM не знаходиться виключно у власності програмної групи. Виклики гнучкої розробки оборонного ПЗ, що виникають через паралельну розробку апаратного та програмного забезпечення, — це насамперед проблема управління конфігурацією: коли апаратні CI змінюють свої специфікації інтерфейсів, програмні CI мають отримувати повідомлення та оновлюватись через формальний процес, а не через неформальне повідомлення в чаті. Документ контролю інтерфейсу (ICD) є контрольованим елементом; зміни до нього вимагають затвердженої пропозиції щодо інженерних змін до початку будь-якої реалізації.

Саме через таку широту оборонні програми підтримують виділений офіс управління конфігурацією (CMO), укомплектований фахівцями, а не покладають обов'язки SCM на розробника як часткове навантаження. CMO веде базу даних управління конфігурацією, готує та головує на CCB, відстежує всі відкриті пропозиції щодо змін і готується до аудитів конфігурації. На програмах із менш ніж 50 особами CMO може бути однією людиною — але це має бути конкретна людина з виділеним часом, а не комітет без чіткого власника.

Типи базових ліній та їх життєвий цикл

MIL-STD-973 визначає три формальних типи базових ліній, що позначають віхи в циклі розробки системи. Кожна базова лінія є контрольованим знімком затвердженої технічної документації для системи або CI на визначеному етапі програми.

Функціональна базова лінія. FBL встановлюється, коли замовник приймає функціональну специфікацію системного рівня на PDR. Вона фіксує, що система має робити — вимоги до продуктивності, функціональні та інтерфейсні вимоги — не визначаючи спосіб реалізації. Після закриття зміни до FBL вимагають ECP класу I та згоди замовника. Команди розробників ПЗ дізнаються про зміни FBL найхворобливіше під час функціональних аудитів конфігурації, коли в контрольному переліку аудиту з'являються вимоги, про які їх офіційно не повідомляли.

Розподілена базова лінія. ABL закривається на CDR і контролює, як вимоги системного рівня розподіляються між CI. Специфікація вимог до програмного забезпечення (SRS) кожного програмного CI прив'язана до ABL. Якщо вимогу системи згодом перерозподіляють — скажімо, вимогу щодо часу переносять з апаратного CI на програмний CI — такий перерозподіл є зміною класу I, яка вимагає затвердження CCB та перегляду SRS до того, як команда розробників ПЗ змінить хоч рядок коду. Програми, що дозволяють неформальний перерозподіл у коридорних розмовах між інженерами, врешті мають SRS, що відображає фактичну реалізацію, а не затверджені вимоги, — і це щоразу провалює FCA.

Продуктова базова лінія. PBL є кульмінацією процесу розробки, встановлюється після того, як фізичний аудит конфігурації підтверджує відповідність поставленого продукту задокументованій конфігурації. PBL включає специфікацію збірки (точна версія вихідного коду, компілятор, ланцюжок інструментів і параметри збірки, необхідні для відтворення поставки), опис версії ПЗ і специфікацію складу виробу в реальному виконанні. Після встановлення PBL продукт переходить під контроль конфігурації стадії супроводу — усі зміни, якими б незначними вони не були, вимагають формальних ECP через CCB.

Структура та робота ради з контролю змін

CCB — це орган прийняття рішень, що оцінює пропоновані зміни до контрольованих базових ліній. Це не рада перегляду чи технічна консультативна група — це формальний орган із задокументованим статутом, визначеним складом і обов'язковими правилами голосування. CCB, яка діє неформально, приймає рішення в імпровізованих листуваннях електронною поштою, а не на формальних засіданнях із протокольними записами, — це не CCB у розумінні MIL-STD-973, і вона не задовольнить вимоги урядового аудиту.

Статут. Статут CCB є контрольованим документом (що сам управляється в рамках SCM) і визначає: повноваження та сферу охоплення CCB; постійний склад і заступників; вимоги до кворуму (зазвичай більшість голосуючих членів); правила голосування для рутинних змін, спірних змін і аварійних процедур; формат подання ECP та необхідну супровідну інформацію; терміни прийняття рішень (наприклад, рутинні ECP вирішуються протягом 10 робочих днів після подання); а також шлях ескалації, коли CCB не може дійти рішення.

Склад для програми середнього розміру. CCB для оборонної програми з 30–100 осіб зазвичай включає:

• Голова: головний інженер або менеджер програми — вирішальний голос, забезпечує дотримання статуту
• Секретар: офіцер з управління конфігурацією — готує порядок денний, веде протоколи, підтримує CMDB
• Голосуючі члени: керівник системної інженерії, керівник ПЗ, керівник апаратного забезпечення, керівник випробувань, представник ILS/логістики
• Учасники без права голосу: ініціатор ECP, керівники відповідних підсистем, аналітик витрат/розкладу
• Представник замовника: COTR або PM — обов'язковий для змін класу I, може бути присутнім або надати письмову згоду

Регулярність засідань. Більшість програм проводять щотижневі засідання CCB для рутинних змін із постійним порядком денним, що включає: статус раніше затверджених ECP; нові ECP, подані з часу останнього засідання (короткий первинний розгляд); повні презентації та голосування по ECP, готових до рішення; і ратифікацію аварійних змін. Аварійні зміни авторизуються позапланово головою CCB (і представником замовника для змін класу I) та ратифікуються на наступному запланованому засіданні CCB — запис ратифікації закриває аварійне дозволення.

Протоколи та записи. Чернетки протоколів мають бути розіслані протягом 48 годин після засідання та остаточно затверджені протягом п'яти робочих днів. Протоколи фіксують: учасників, кворумний статус, розглянуті ECP з рішенням і підрахунком голосів, пункти дій із відповідальними особами та термінами виконання, а також будь-які особливі думки щодо спірних рішень. Протоколи є контрольованими документами, що зберігаються в CMDB. Послідовність секретаря CCB у підготовці та поданні протоколів є одним із найвагоміших факторів готовності програми до аудиту конфігурації.

Пропозиції щодо інженерних змін: клас I проти класу II

Пропозиція щодо інженерних змін (ECP) — це формальний інструмент для пропонування, оцінювання та затвердження змін до контрольованої базової лінії. Кожна зміна до елемента конфігурації, яка впливатиме на FBL, ABL або PBL, повинна бути задокументована в ECP до початку реалізації — а не після.

Клас I проти класу II. Відмінність визначає, хто затверджує зміну і скільки процедур вона потребує:

• Клас I: впливає на офіційно контрольовану базову лінію, контрактне зобов'язання, затверджений інтерфейс (ICD), вимогу безпеки або форму/придатність/функцію поставки. Вимагає затвердження CCB і згоди замовника. Реалізація блокується до отримання дозволу. Типові приклади: додавання нової можливості до SRS, зміна поля даних в ICD, модифікація вимоги безпеки, видалення процедури випробувань із затвердженого плану.
• Клас II: внутрішня технічна зміна, яка не впливає на жодну контрольовану базову лінію, контрактний результат або затверджений інтерфейс. Затверджується внутрішньою CCB підрядника без участі замовника. Фіксується для журналу аудиту, але не підлягає урядовому перегляду. Типові приклади: рефакторинг внутрішньої структури модуля, зміна структури даних без виходу за межі інтерфейсу, оновлення внутрішніх стандартів кодування в стильовому посібнику, який не є CDRL.

Межа між класом I і класом II є частим джерелом суперечок. CMP повинен визначати цю межу з розробленими прикладами. Поширена помилка — коли інженери самостійно вирішують, що їх зміна є класом II, хоча насправді вона клас I: зміна внутрішнього формату даних повідомлення, що перетинає межу CI, є зміною класу I, навіть якщо зовнішній інтерфейс (ICD) здається незмінним, оскільки формат повідомлення є неявним інтерфейсом.

Оцінка впливу. Кожна ECP вимагає структурованої оцінки впливу перед тим, як по ній можна проголосувати. Оцінка охоплює: технічний ризик (що може піти не так із запропонованою зміною?); вплив на розклад (скільки днів це додає до розкладу, включаючи регресійне тестування?); вплив на вартість (яка орієнтовна вартість трудових і матеріальних витрат?); вплив на безпеку (чи впливає ця зміна на будь-яку критичну функцію безпеки або припущення аналізу безпеки?); і вплив на інтерфейс (які інші CI, якщо такі є, повинні внести відповідні зміни?). Для змін класу I оцінку впливу готують спільно інженер-ініціатор, аналітик витрат/розкладу та системний інженер. Для змін, що мають вплив на безпеку, інженер безпеки переглядає та підписує оцінку до подання в CCB.

Життєвий цикл ECP: ініціатор готує ECP → секретар CM присвоює номер і реєструє в CMDB → CCB розглядає на засіданні → CCB голосує (затвердити / відхилити / відкласти) → для класу I отримується згода замовника → статус ECP оновлюється до «Затверджено для реалізації» в CMDB → інженер реалізує зміну → коміт до системи контролю версій позначається номером ECP → свідчення тестування прив'язується до ECP у CMDB → ECP закривається. Цей повний журнал аудиту — від ініціації через реалізацію до свідчень тестування — саме те, що урядові аудитори шукають під час FCA та PCA. Дивіться також наш матеріал про застосування SBOM в оборонних конвеєрах, який перетинається з управлінням ECP для змін у ланцюжку постачання ПЗ.

Інструментарій управління конфігурацією ПЗ

Інструментарій SCM для оборонної програми повинен задовольняти три обмеження, що не застосовуються в комерційній розробці: інструменти повинні бути прийнятними в рамках дозволу на функціонування (ATO) програми; вони мають підтримувати формальну простежуваність, яку вимагають MIL-STD-973 та будь-який застосовний стандарт льотної придатності; і — для більшості оборонних програм — вони повинні функціонувати в ізольованому або частково ізольованому мережевому середовищі.

Контроль версій. Git є де-факто стандартом в оборонних програмах, як несекретних, так і секретних. Для секретних програм самостійно розгорнуті Git-сервери (GitLab Self-Managed, Bitbucket Data Center або Gitea) розгортаються всередині акредитованого анклаву. Правила захисту гілок забезпечують вимоги до перегляду; підписані коміти забезпечують невідмовність для журналу аудиту. Угоди про іменування репозиторіїв і гілок повинні бути задокументовані в CMP та забезпечені через серверні хуки. Для програм із зобов'язаннями DO-178C система контролю версій є кандидатом на кваліфікацію інструменту — TQP повинен охоплювати конкретну версію сервера, конфігурацію та операцію мітки базової лінії, що живить поставку опису версії ПЗ. Для ширшого контексту запуску CI/CD у таких середовищах дивіться наш матеріал про CI/CD для ізольованих оборонних мереж.

Управління вимогами. IBM Engineering Requirements Management DOORS (класичний і наступного покоління) залишається найпоширенішим інструментом управління вимогами в оборонних програмах, зокрема тих, що регулюються MIL-STD-973 і DO-178C. Jama Software і PTC Windchill Requirements є поширеними альтернативами. Інструмент управління вимогами повинен підтримувати двонаправлену простежуваність (вимога → тестовий випадок → результат тесту) та генерувати артефакти матриці простежуваності, потрібні SDP/SCMP як CDRL. Сам інструмент повинен функціонувати під контролем конфігурації: база даних вимог є елементом конфігурації, зміни до вимог в інструменті контролюються, а виведення інструменту повинно бути відтворювальним із позначеної базової лінії.

База даних управління конфігурацією. CMDB відстежує статус CI, зв'язки з базовими лініями, записи ECP, записи відхилень/допусків і дані обліку статусу конфігурації. У великих програмах CMDB часто є IBM Engineering Lifecycle Management (ELM) або налаштованим екземпляром Jira з плагіном CM. Менші програми іноді використовують дисципліновану комбінацію Confluence + Jira. Незалежно від вибору, CMDB повинна бути в межах акредитованої зони, мати засоби контролю доступу, що запобігають несанкціонованій модифікації затверджених записів, і генерувати періодичний звіт про статус конфігурації, що є CDRL у більшості програм.

Налаштування SCM-сервера в ізольованому середовищі. Самостійно розгорнутий Git-сервер і CMDB розгортаються на примірниках RHEL, захищених відповідно до STIG, всередині секретного анклаву. Жодного з'єднання з публічними сервісами хостингу репозиторіїв. Оновлення пакетів серверного ПЗ дотримуються процедури передачі носіїв програми. TLS-сертифікати сервера видаються внутрішньою PKI програми. Резервні копії зберігаються в анклаві з використанням зашифрованого сховища з задокументованими процедурами відновлення. Доступ до сервера контролю версій регулюється списком контролю доступу програми з рольовими дозволами, що розмежовують читання, запис і адміністративний доступ.

Аудити конфігурації: FCA та PCA

Аудити конфігурації — це формальні перевірки, що проводяться за участю або з відома представників замовника для підтвердження відповідності CI або системи встановленим вимогам (FCA) і точності документування продукту (PCA). Це не необов'язкові контрольні точки — це контрактні віхи, що визначають постачання та платежі.

Функціональний аудит конфігурації (FCA). FCA перевіряє, що програмний CI задовольнив усі розподілені вимоги. Урядова аудиторська група переглядає: затверджену SRS (документ ABL) із кожною вимогою; процедури випробувань для кожної вимоги; результати випробувань із підтвердженням успішного виконання; матрицю простежуваності, що зв'язує вимоги з тестами і результатами; і звіти про відкриті невідповідності з відображенням усіх відомих аномалій та їх статусом вирішення. Поширеним аудиторським зауваженням є вимоги без відповідного тесту — «вимоги-сироти», які команди планували протестувати, але офіційно не охопили. Не менш поширені процедури випробувань, що нібито задовольняють вимогу, але насправді тестують щось суміжне з нею — аудитори читають процедури дослівно відносно тексту вимог. Підготовка до FCA вимагає генерації матриці простежуваності з інструменту управління вимогами за 60+ днів, її перегляду на прогалини та усунення або документування цих прогалин до аудиту.

Фізичний аудит конфігурації (PCA). PCA перевіряє, що продукт, призначений для постачання або розгортання, точно відповідає задокументованій конфігурації. Основна демонстрація — відтворюваність збірки: підрядник повинен показати, що, починаючи з контрольованої базової лінії вихідного коду, зазначеної в описі версії ПЗ, можна відтворити двійковий файл, побайтово ідентичний поставці. Це вимагає повної специфікації середовища збірки — не лише версії компілятора, а й кожного інструменту в ланцюжку збірки, кожного прапору збірки, кожної змінної середовища, що впливає на результат. Програми з незадокументованими залежностями середовища збірки виявляють цю проблему на PCA; рішення — підтримувати середовище збірки як контрольований конфігурацією образ контейнера, точний зміст якого є частиною документації PBL.

# 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: підтвердити, що тег контролю версій, що відповідає SVD, існує і підписаний; згенерувати специфікацію складу виробу з CMDB і порівняти її з фактичним набором пакетів у середовищі збірки; перевірити, що всі затверджені відхилення та допуски задокументовані і підписані; і підтвердити, що перелік відкритих питань відповідає розділу відомих аномалій SVD. Будь-яка розбіжність між записом CMDB і фізичним продуктом є аудиторським зауваженням, яке має бути усунуте до закриття PCA.

Інтеграція MIL-STD-973 та DO-178C

Програми, що виробляють бортове програмне забезпечення, повинні задовольняти як MIL-STD-973 (стандарт SCM оборонних закупівель), так і DO-178C розділ 7 (управління конфігурацією ПЗ для сертифікації бортового ПЗ). Обидва стандарти є взаємодоповнювальними, але мають різні акценти та результати.

План управління конфігурацією проти плану управління конфігурацією ПЗ. MIL-STD-973 вимагає CMP системного рівня як CDRL. DO-178C вимагає окремого плану управління конфігурацією ПЗ (SCMP) як елемента даних життєвого циклу ПЗ. SCMP повинен описувати, як усі дані життєвого циклу ПЗ (SLCD) ставляться під контроль конфігурації, як управляються зміни, як встановлюються базові лінії та як працює процес звітування про проблеми та контролю змін. SCMP переглядається DER (уповноваженим представником з інженерії) або органом сертифікації як частина перегляду планування ПЗ. CMP системного рівня та SCMP повинні бути узгодженими та містити перехресні посилання, але це різні документи з різною аудиторією.

CDRL з управління конфігурацією. Типові CDRL оборонної програми, пов'язані з CM, включають:

• DI-CMAN-80858A — план управління конфігурацією: головний документ процесу SCM
• DI-CMAN-81259 — звіт про статус конфігурації: періодичне зведення статусу CI
• DI-CMAN-81000 — пропозиція щодо інженерних змін: результат по кожній зміні
• DI-MCCR-80013A — опис версії ПЗ: результат по кожному випуску
• DI-CMAN-81121 — документ контролю інтерфейсу: результат по кожному інтерфейсу

Кваліфікація інструментів SCM. DO-178C і супутній стандарт DO-330 вимагають кваліфікації інструментів розробки — таких, чий результат стає частиною бортового ПЗ або чия відмова може призвести до непомічених помилок. Система контролю версій, чия позначена базова лінія живить результат SVD, є кандидатом на кваліфікацію TD3 за DO-330. Свідчення кваліфікації включають оперативні вимоги до інструменту (TOR), план кваліфікації інструменту, записи тестування, що демонструють коректну роботу, і процес звітів про проблеми для самого інструменту. Програми виявляють цю вимогу пізно, вже після вибору та розгортання сервера контролю версій, оскільки вимогу DO-178C часто розуміють як таку, що стосується лише компіляторів і генераторів коду. Початок плану кваліфікації інструменту для інструменту SCM одночасно зі SCMP — під час планування ПЗ — запобігає авральній кваліфікації в останню хвилину, що затримує сертифікацію.

Звітування про проблеми та контроль змін. DO-178C розділ 7.3 вимагає задокументованого процесу звітування про проблеми для всіх даних життєвого циклу ПЗ, що перебувають під контролем CM. Кожна аномалія — не лише дефекти коду, а й помилки у вимогах, процедурах випробувань, проектній документації та аналітичних звітах — повинна бути внесена до системи звітування та доведена до закриття. Дані звітів про проблеми живлять FCA (відображаючи відкриті аномалії та їх вирішення) і PCA (підтверджуючи точність і повноту переліку відомих аномалій у SVD). Інтеграція системи звітування про проблеми з робочим процесом ECP забезпечує автоматичне генерування ECP для проблем, що вимагають зміни базової лінії, — замість того, щоб вони зберігалися в окремому трекері дефектів, який аудитори не можуть співвіднести з контрольованою базовою лінією.

Програми, що інвестують у цю інтеграцію — інструмент управління вимогами, що передає простежуваність до інструменту управління тестуванням, який передає результати до CMDB, пов'язаної з робочим процесом ECP, — мають значно коротші цикли FCA та PCA і менше зауважень після аудиту, ніж програми, що управляють цими записами у розрізнених таблицях. Інвестиції суттєві, але альтернатива — відтворення аудиторських свідчень під часовим тиском у присутності урядових представників — коштує дорожче і завдає більше шкоди відносинам у рамках програми.