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

СММ

У листопаді 1986 р. американський інститут Software Engineering Institute (SEI) спільно з Mitre Corporation почав розробку огляду зрілості процесів розробки програмного забезпечення, який був призначений для допомоги в поліпшенні їх внутрішніх процесів [31].

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

У вересні 1987 р. SEI випустив короткий огляд процесів розробки ПО з описом їх рівнів зрілості, а також опитувач, що призначався для виявлення областей в компанії, в яких були потрібні поліпшення. Проте більшість компаній розглядали цей опитувач як готову модель, внаслідок цього через 4 року запитальник був перетворений в реальну модель, Capability Maturity Model for Software (CMM). Перша версія CMM (Version 1.0), що вийшла в 1991 р., в 1992 р. була переглянута учасниками робочої зустрічі, в якій брали участь близько 200 фахівців в області ПО, і членами суспільства розробників.

В результаті був випущений стандарт CMM, Version 1.1, який до теперішнього часу активно використовується у всьому світі.

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

Постійне поліпшення процесів базується на поступовому вирощенні культури компанії, а не на проведенні революційних інновацій. У СММ представлена схема такого поступового поліпшення, розділена по п'яти рівнях зрілості процесів. Ці п'ять рівнів є шкалою (мал. 2.4) для оцінки рівня зрілості процесів розробки ПО в компанії і для виміру їх параметрів.

Приведемо основні характеристики кожного рівня :

Початковий рівень. Процес розробки носить хаотичний характер. Визначені лише небагато з процесів, і успіх проектів залежить від конкретних виконавців.

Повторюваність. Встановлені основні процеси управління проектами: відстежування витрат, графіка робіт і функціональності.

Мал. 2.4. Принцип послідовного підвищення рівня зрілості : можливості розвитку організації

Впорядковані деякі процеси, необхідні Для того, щоб повторити попередні досягнення на аналогічних проектах (проектах з аналогічними застосуваннями).

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

Контроль. Збираються детальні кількісні дані по функціонуванню процесів розробки і якості кінцевого продукту. Аналізується значення і динаміка цих даних.

Поліпшення якості. Постійне поліпшення процесів грунтується на кількісних даних по процесах і на пробному впровадженні нових ідей і технологій.

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

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

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

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

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

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

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

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