Сертифікація ПЗ з участю користувачів

Модель обмеженої гарантії на ПЗ

Компонентна розробка програм (CBSE – component based software engineering) припускає створення програмних систем з фрагментів. Переваги різних технологій обговорюються багато років, але немає жодних ознак того, що компонентна розробка ось-ось стане стандартним підходом до створення програмних систем.

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

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

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

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

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

Розробник програмного забезпечення представляє кінцевий продукт для включення в нього резидентного інструментарію тестування, в результаті цього створюється спеціальна, «інструментальна» копія. Розробник надає копії SCL, яка передає інструментальну копію попередньо відібраним користувачам, які працюють в різних сферах. Ці тестувальники будуть використовувати продукт по узгодженості з SCL. Запропонована Microsoft модель бета-тестування – прекрасний приклад того, як серед всіх бажаючих відібрати тільки тих, хто дійсно зможе надати найбільше корисної інформації.

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

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

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

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

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

Дата добавления: 2014-01-04