Оцінка якості процесів створення програмного забезпечення

 

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

· міжнародні стандарти серії ISO 9000 (ISO 9000 – ISO 9004);

· CMM – Capability Maturity Model – модель зрілості (вдосконалення) процесів створення програмного забезпечення, запропонована SEI (Software Engineering Institute – інститут програмування при університеті Карнегі – Меллон);

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

 

Серія стандартів ISO 9000

 

Однією з найважливіших проблем забезпечення якості програмних засобів є формалізація характеристик якості і методологія їх оцінки. Для визначення адекватності якості функціонування, наявності технічних можливостей програмних засобів до взаємодії, вдосконалення і розвитку необхідно використовувати стандарти в області оцінки характеристик їх якості. Основою регламентування показників якості програмних засобів раніше був міжнародний стандарт ISO 9126:1991 «Інформаційна технологія. Оцінка програмного продукту. Характеристики якості і керівництво по їх використанню». Завершується розробка і формалізований останній проект який складається з чотирьох частин стандарту ISO 9126–1 – ISO 9126–4 для заміни невеликої редакції 1991 р. Проект складається з чотирьох частин під загальним заголовком «Інформаційна технологія – характеристики і метрики якості програмного забезпечення»: «Частина 1. Характеристики і субхарактеристики якості»; «Частина 2. Зовнішні метрики якості»; «Частина 3. Внутрішні метрики якості»; «Частина 4. Метрики якості у використанні».

Перша частина стандарту – ISO 9126–1 – розподіляє атрибути якості програмних засобів по шести характеристикам, які використовуються у інших частинах стандарту. Виходячи з принципіальних можливостей їх зміни всі характеристики можуть бути об’єднані в три групи, до яких застосовні різні категорії метрик:

· категорійним чи описовим (номінальним) метрикам найбільш адекватні функціональні можливості програмних засобів;

· кількісні метрики застосовні для вимірювання надійності та ефективності складних комплексів програм;

· якісні метрики у найбільшій степені відповідають практичності, супроводжувальності та мобільності програмних засобів.

У частині стандарту ISO 9126–1 даються означення з уточненнями з іших його частин для кожної характеристики програмного засобу, а також для субхарактеристик якості.

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

Друга і третя частини стандарту – ISO 9126–2 та ISO 9126–3, присвячені формалізації відповідно зовнішніх та внутрішніх метрик характеристик якості складних програмних засобів. Всі таблиці містять уніфіковану рубрикацію, де відображені ім’я і призначення метрики; метод її використання; спосіб вимірювання, тип шкали метрики; тип вимірюваної величини; початкові дані для вимірювання та порівняння; а також етапи життєвого циклу програмного засобу (по ISO 12207), до яких може бути використана метрика.

Четверта частина стандарту ISO 9126–4 – призначена для покупців, поставщиків, розробників, користувачів та менеджерів якості програмних засобів. В ній обґрунтовуються і коментуються виділені показники сфери (контексту) використання програмних засобів і групи вибраних метрик для користувачів.

 

Вибір показників якості

 

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

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

· вибір та обґрунтування набору початкових даних, які відображають загальні особливості та етапи життєвого циклу проекту програмного засобу та його користувачів, кожен з яких впливає на певні характеристики якості комплексу програм;

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

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

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

 

Оцінка якості

Методології і стандартизації оцінки характеристик якості готових програмних засобів та їх компонент (програмного продукту) на різних етапах життєвого циклу присвячений міжнародний стандарт ISO 14598, який складається з шести частин. Рекомендується наступна загальна схема процесів оцінки характеристик якості програм:

· встановлення початкових вимог для оцінки – визначення цілей випробувань, ідентифікація типу метрик програмного засобу, виділення адекватних показників і необхідних значень атрибутів якості;

· селекція метрик якості, встановлення рейтингів і рівнів пріоритету метрик субхарактеристик і атрибутів, виділення критеріїв для проведення експертиз та змін;

· планування і проектування процесів оцінки характеристик та атрибутів якості в життєвому циклі програмного засобу;

· виконання вимірювань для оцінки, порівняння результатів з критеріями і вимогами, узагальнення та оцінка результатів.

Для кожної характеристики якості рекомендується формувати міри та шкалу вимірювань з виділенням необхідних, допустимих та незадовільних значень. Реалізація процесів оцінки повинна корелювати з етапами життєвого циклу конкретного проекту програмного засобу у відповідності з адаптованою версією стандарту ISO 12207.

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

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

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

Оцінка захищеності програмних засобів включає визначення повноти використання методів і засобів захисту програмного засобу від потенційних загроз і досягнутою при цьому безпеки функціонування інформаційної системи. Найбільш широко і детально методологічні і системні задачі оцінки комплексного захисту інформаційних систем викладені в трьох частинах стандарту ISO 15408:1999-1 – ISO 15408:1999-3 «Методи і засоби забезпечення безпеки. Критерії оцінки безпеки інформаційних технологій».

Оцінка надійності – вимірювання кількісних метрик атрибутів субхарактеристик у використанні: завершеності, стійкості до дефектів, відновлюваності та доступності/готовності.

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

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

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

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

 

Система управління якістю

 

Вибір характеристик та оцінка якості програмних засобів – лише одна із задач в області забезпечення якості продукції. Комплексне розв’язання задач забезпечення якості програмних засобів припускає розробку та впровадження тої чи іншої системи управління якістю. У світовій практиці найбільше поширення отримала система, основана на міжнародних стандартах серії 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. Покращення якості. Постійне покращення процесів основується на кількісних даних по процесам і на пробному впровадженні нових ідей і технологій.