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

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

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

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

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

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

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

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

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

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

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

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