AQAP 2210 забезпечення якості програмного забезпечення

Що це таке

AQAP-2210 є Allied Quality Assurance Publication NATO, що додає специфічні для програмного забезпечення вимоги забезпечення якості поверх того з AQAP-2110 або AQAP-2310, який уже називає контракт. Його ніколи не використовують самого: сама публікація каже, що він "may only be used as a software supplement to AQAP-2110 or AQAP-2310." Він вводить AS9115, специфічне для програмного забезпечення доповнення до AS9100, і де його використовують разом з AQAP-2110, він підставляє ISO 9001 замість кожного посилання, яке AS9115 робить на AS9100. Він також перетворює кожне "should" в AS9115 на обов'язкове "shall," якщо замовник не погодиться інакше, і каже, що де специфічна для NATO вимога в розділі 5 суперечить AS9115, перемагає специфічна для NATO вимога. Поточне видання - Видання B, версія 1, промульговане в серпні 2022 року, замінює AQAP-2210 Видання A версію 2.

Сам по собі він не має сили. Розділ 1.3 каже, що публікація "is primarily intended for use in a contract between two or more parties, in conjunction with AQAP-2110 or AQAP-2310," і що "when referenced in a contract, this publication shall apply to all the processes necessary for the Supplier to fulfil the contractual requirements." Застосовність сягає далі за замовне розроблення до непризначеного для поставки програмного забезпечення, супроводу програмного забезпечення, незамовного і готового програмного забезпечення і програмного елемента мікропрограмного забезпечення там, де контракт його викликає. Постачальник може також ухвалити його добровільно і внутрішньо без вимоги контракту, і де контракт і публікація розходяться, перемагає контракт.

Кого він зобов'язує і як

Публікація сама не визначає постачальника, замовника чи Представника з урядового забезпечення якості (GQAR); вона запозичує їх із документів під собою: "The applicable definitions of ISO 9000 or AQAP-2110 or AQAP-2310 or AS9115 apply to the terminology used in this publication." Власна передмова обрамлює весь документ як вимоги замовника до підрядника: "The Acquirer's software quality assurance requirements stated in this document, are based on the experience that quality management of the entire software development process is the key to achieving software quality in complex and mission critical computer systems such as weapon systems, communication systems, and command and control systems." У розділах вимог наскрізь діяти наказано постачальнику, а замовник і/або GQAR отримують, переглядають і можуть відхилити отримані плани.

Оскільки практичне питання ніколи не «чи це застосовується до нас», а «чи контракт його називає», момент, коли він стає реальним, раніше, ніж більшість постачальників помічає: План якості програмного забезпечення проєкту (PSQP), якого він вимагає, має звертатися до контрактних вимог і бути поданим до початку робіт.

Адаптація за критичністю і категорією розроблення

Адаптувати можна лише розділ 5, і навіть там кілька підпунктів зафіксовані і їх не можна видалити, знизити або змінити: загальні положення, сам PSQP, аналіз критичності програмного забезпечення, організаційні ролі та відповідальність, управління субпостачальниками, управління конфігурацією програмного забезпечення та інфраструктура. Адаптація масштабує вимоги до двох речей. По-перше, критичність у чотирьох категоріях на основі тяжкості наслідків відмови системи: «A» для програмного забезпечення, відмова якого може спричинити катастрофічні наслідки для безпеки або успіху місії, далі через «B» (критичні або небезпечні) і «C» (значні) до «D» (незначні або нехтовні). По-друге, категорія розроблення в чотирьох рівнях на основі обсягу розроблення, випробувань, інспекції або контролю, що потрібні: «1» охоплює все замовне розроблення або супровід і повторно використане або відкрите програмне забезпечення зі значною інтеграцією; «4» охоплює комерційне готове програмне забезпечення з мінімальною інтеграцією. Кожне рішення адаптації має бути узгоджене між замовником і постачальником, відображене в контракті і задокументоване в PSQP з обґрунтуванням.

План якості програмного забезпечення проєкту

PSQP є документом, через який постачальник демонструє відповідність. Він несе підписи схвалення, стоїть під контролем конфігурації і має "document and maintain traceability of all the requirements from the project process by including a requirement and solution compliance matrix, justifying fulfilment of all the requirements of this publication" - тож аудитор очікує живу матрицю, а не наративну заяву. Він також охоплює метод аналізу критичності, модель якості, виведену з ISO/IEC 25010 або еквівалента, і відповідний обсяг операційного планування і контролю, і його треба переглядати і оновлювати на наперед визначених віхах проєкту. Замовник і/або GQAR може відхилити PSQP або будь-яку його редакцію.

Управління конфігурацією, випуски і латки

Управління конфігурацією програмного забезпечення має підтримувати цілісність і простежуваність протягом розроблення, запобігати неконтрольованим змінам і надавати заплановані та випущені базові лінії, з процедурами ідентифікації, контролю змін, звітності про статус, аудитів і координації зовні розроблених елементів. Двостороння простежуваність вимагається між системними, програмними і компонентними вимогами і між вимогами, валідаційними випробуваннями і результатами випробувань, збережена "in a matrix and/or in a dedicated tool" - із приміткою, що COTS і частково змінене програмне забезпечення може дозволяти лише часткову простежуваність. Кожен перегляд і поставка потребує звіту конфігурації випуску програмного забезпечення, що називає версію програмного забезпечення, носій поставки, застосовні специфікації, процедуру збірки, супровідну документацію, змінені елементи конфігурації, статус відхилень і відмовлень і переліки виправлених і невирішених несправностей, класифікованих за тяжкістю.

Латки мають власне, суворіше правило: їх використання "is prohibited except for urgent corrections with agreement of the Acquirer," будь-яка латка має залишатися тимчасовою до включення до остаточної версії і потребує власного звіту конфігурації латки, що охоплює дослідження впливу, виправлені несправності, процедуру встановлення і випробування на відсутність регресії, проведені щодо неї.

Оцінювання, верифікація, валідація і випробування

Постачальник має планувати формальний процес оцінювання, верифікації та валідації (EVV), що охоплює методи, об'єкти, критерії, інструменти і документацію, яку він виробляє, із заходами оцінювання характеристик якості програмного забезпечення, які задають вимоги або PSQP. Люди, що проводять EVV, потребують "an appropriate level of independence from the person(s) who developed the software product," і документ прямо каже, що діяльність EVV замовника або GQAR "shall not constitute acceptance, nor shall it in any way replace EVV activities by the Supplier or otherwise relieve the Supplier of its contractual responsibilities." Випробування охоплюють рівні елемента, інтеграції, системи і прийняття, з контрольованими середовищами випробувань і засвідченням звітів випробувань; кожен фрагмент документації програмного забезпечення треба переглянути і схвалити до випуску.

Супровід і чого документ не охоплює

Де супровід програмного забезпечення є контрактною вимогою після початкової поставки, постачальник надає План супроводу до початку фази супроводу, що охоплює роботу, процедури, записи, відповідальність, управління конфігурацією виробу, що супроводжується, повідомлення про несправності і їх вирішення, і випробування та прийняття змін.

AQAP-2210 не фіксує власної моделі, методу чи життєвого циклу розроблення: він залишає постачальнику адаптувати "the required documentation and procedures to the specific development and procurement processes of the project." Він не називає схеми сертифікації і акредитованого органу: те, що він описує наскрізь, - урядове забезпечення якості, яке проводить замовник або призначений GQAR безпосередньо щодо контракту, включно на майданчиках субпостачальників, коли просять.

Стандарти, на які він посилається

• AQAP-2110Довідково
• AQAP-2310Довідково
• ISO 9001Довідково
• AQAP-2000Довідково
• STANREC 4814Довідково
• AAP-48Довідково
• ISO/IEC 27001Довідково
• AQAP-2105Довідково
• ISO 31000Довідково
• AQAP-2070Довідково