2.2.3. Процес сертифікації програм на базі інформації про їх використання

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

Методів сертифікації якості програмного забезпечення стає все більше. Популярні підходи, основані на процесах, такі як ISO 9000 та SEI-CMM, примушують творців програмного забезпечення жорстко притримуватись вибраних стандартів та процесів розробки. Такі підходи часто вимагають участі аудиторів, які перевіряють документацію виробника і те, як він виконує дану ним обіцянку. Але навіть якщо аудитор по сертифікації може переконатись в чистоті намірів виробника, одна ця перевірка не гарантує, що створюване програмне забезпечення буде високої якості.

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

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

Організації, які виконують таку сертифікацію, називаються лабораторіями по сертифікації програмного забезпечення (Software Certification Laboratories – SCL). Їх переваги в тому, що вони зможуть надати рівні можливості всім виробникам, якщо, звичайно, кожний продукт буде тестуватись в рівних умовах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переваги моделі сертифікації з участю користувачів

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

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

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