Процес сертифікації програм на базі інформації про їх використання
СММ
Система управління якістю
Вибір характеристик та оцінка якості програмних засобів – лише одна із задач в області забезпечення якості продукції. Комплексне розв’язання задач забезпечення якості програмних засобів припускає розробку та впровадження тої чи іншої системи управління якістю. У світовій практиці найбільше поширення отримала система, основана на міжнародних стандартах серії ISO 9000, яка включає більше десятка документів, у тому числі стандарт, який регламентує забезпечення якості ПЗ (ISO 9000/3).
Визначення характеристик і субхарактеристик якості (ISO 9126-1):
Функціональні можливості – здатність програмного засобу забезпечувати розв’язування задач, які задовольняють сформульовані вимоги замовників та користувачів при використанні комплексу програм в заданих умовах.
Функціональна пригодність –набір і описання субхарактеристики та її атрибутів, які визначають призначення, номенклатуру, основні, необхідні і достатні функції програмного засобу, відповідного технічному завданню та специфікаціям вимог замовника чи потенційного користувача.
Правильність (коректність) –здатність програмного засобу забезпечувати правильні чи припустимі результати для користувача результати і зовнішні ефекти.
Здатність до взаємодії– властивість програмних засобів та їх компонент взаємодіяти з однією чи більшим числом компонент внутрішнього чи зовнішнього середовища.
Захищеність– здатність компонент програмного засобу захищати програми та інформацію від будь-яких негативних впливів.
Надійність – забезпечення комплексом програм достатньо низької ймовірності відмови в процесі функціонування програмного засобу в реальному часі.
Ефективність– властивість програмного засобу, яке забезпечує необхідну продуктивність розв’язування функціональних задач, з врахуванням кількості обчислювальних ресурсів в установлених умовах.
Практичність– властивість програмного засобу, яка обумовлює складність його розуміння, вивчення та використання, а також привабливість для кваліфікованих користувачів при використанні при вказаних умовах.
Супроводжуваність – можливість програмного засобу до модифікації та зміни конфігурації та функцій.
Мобільність– підготовленість програмного засобу до перенесення з одного апаратно-операційного середовища в інше.
У листопаді 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, який до нашого часу активно використовується у всьому світі.
Причини такої зацікавленості до CMM зрозумілі. Не дивлячись на те що самі розробники ПЗ, та їх керівництво часто дуже добре знають свої постійні проблеми, вони не можуть прийти до єдиного висновку про те, які зміни необхідні компанії в першу чергу. Без розробки єдиної стратегії проведення покращень керівництво не може знайти взаєморозуміння зі своїми співробітниками відносно найбільш пріоритетних задач по покращенню. Для досягнення максимального результату від зусиль, потрачених на покращення процесів, необхідно мати поетапну стратегію розвитку, яка дозволить покращувати зрілість процесів розробки поступово, еволюційним шляхом.
Постійне покращення процесів базується на поступовому вирощуванні культури компанії, а не на проведенні революційних інновацій. В CMM представлена схема такого поступового покращення, розділена по п’яти рівням зрілості процесів. Ці п’ять рівнів представляють собою шкалу (рис. 2.4) для оцінки рівня зрілості процесів розробки ПЗ в компанії і для вимірювання їх параметрів.
Приведемо основні характеристики кожного рівня:
1. Початковий рівень. Процес розробки носить хаотичний характер. Визначені лише деякі з процесів, і успіх проектів залежить від конкретних виконавців.
2. Повторюваність. Встановлені основні процеси управління проектами: відслідкування затрат, графіка робіт і функціональності. Впорядковані деякі процеси, необхідні для того, щоб повторити попередні досягнення на аналогічних проектах (проектах з аналогічними додатками).
3. Розробка. Процеси розробки ПЗ і управління проектами описані і впроваджені в єдину систему процесів компанії. У всіх проектах використовується стандартний для організації процес розробки і підтримки ПЗ, адаптований під конкретний проект.
4. Контроль. Збираються детальні кількісні дані по функціонуванню процесів розробки і якості кінцевого продукту. Аналізуються значення і динаміка цих даних.
5. Покращення якості. Постійне покращення процесів основується на кількісних даних по процесам і на пробному впровадженні нових ідей і технологій.
Це новий підхід до сертифікації, який, як стверджують його розробники, дає надійні гарантії якості для комерційних програмних пакетів.
Методів сертифікації якості програмного забезпечення стає все більше. Популярні підходи, основані на процесах, такі як ISO 9000 та SEI-CMM, примушують творців програмного забезпечення жорстко притримуватись вибраних стандартів та процесів розробки. Такі підходи часто вимагають участі аудиторів, які перевіряють документацію виробника і те, як він виконує дану ним обіцянку. Але навіть якщо аудитор по сертифікації може переконатись в чистоті намірів виробника, одна ця перевірка не гарантує, що створюване програмне забезпечення буде високої якості.
Приймаючи до уваги цю проблему, можна припустити методологію сертифікації, яка не вимагає, щоб виробник давав клятви, а аудитори перевіряли, наскільки ці клятви виконуються. Можна із впевненістю сказати, що тільки повністю незалежна сертифікація продукту і є той підхід, якому можуть довіряти користувачі.
Запросивши третю сторону для видачі сертифікатів якості на програмне забезпечення, розробники знімуть з себе відповідальність, як це робить лікар, запрошуючи для консультації іншого лікаря або проводячи ще один аналіз. Кінцеві користувачі також виграють від того, що безпристрасна оцінка продукту буде даватись незалежними організаціями. Таким чином, є вагомі причини для появи організацій, які будуть сертифікувати якість програмного забезпечення.
Організації, які виконують таку сертифікацію, називаються лабораторіями по сертифікації програмного забезпечення (Software Certification Laboratories – SCL). Їх переваги в тому, що вони зможуть надати рівні можливості всім виробникам, якщо, звичайно, кожний продукт буде тестуватись в рівних умовах.
SCL до цього часу не отримали широкого поширення через відповідальність, яку бере на себе ця організація. Якщо сертифіковане ПЗ не оправдає очікувань при його використанні в реальному виробничому процесі, той хто видав сертифікат, несе за це визначену відповідальність. Суди в США відомі своєю вимогливістю до тих, хто називає себе професіоналами, чи то лікарі, юристи та інженери.
Ось і SCL можуть загубити своє реноме і позбутись права займатись сертифікацією у випадку помилки. Щоб дещо знизити ризик, необхідно використовувати точні методи при прийнятті рішення про сертифікацію – в ідеалі автоматизовані. На жаль, навіть якщо SCL використовує кращі методики статистичного аналізу і динамічного тестування, не завжди можна зрозуміти, під який вплив насправді попаде програма в руках користувача. Таким чином, SCL стикається з проблемою точного визначення того, як буде вести себе програмна система – саме головне, що вимагається від вповноважених по видачі сертифікатів.
Процес сертифікації, про який йде мова, використовує автоматизовані процедури, що дозволяють відмовитись від послуг аудиторів. Цей процес використовує ресурси тестування кінцевими користувачами, опираючись на перевірені методи, подібні до тих, завдяки яким Linux стала самою популярною і надійною із всіх різновидів UNIX. Запропонований процес, повністю оснований на продуктах, як таких, оцінює якість роботи програмного забезпечення, а не якість процесів створення коду.