Якість програмного забезпечення

 

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

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

Стандарт ISO 9126:2001 регламентує зовнішні і внутрішні характеристики якості. Перші відображають вимоги до функціонування програмного продукту. Для кількісного встановлення критеріїв якості, за якими буде здійснюватися перевірка і підтвердження відповідності ПЗ заданим вимогам, визначаються відповідні зовні­шні вимірювані властивості (зовнішні атрибути,) ПЗ, метрики (наприклад, час виконання окремих компонентів), діапазони зміни значень і моделі їх оцінки. Метрики використовуються на стадії тестування або функціонування і називаються зовнішніми метриками. Вони являють собою моделі оцінки атрибутів.

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

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

Остаточна оцінка якості проводиться відповідно до стандарту ISO/IEC 14598. Якість може підвищуватися за рахунок постійного поліпшення використовуваного продукту виявленням, усуненням дефектів у ПЗ і їх запобіганням.

Область знань «Якість ПЗ (Software Quality)» складається з наступних розді­лів:

- концепція якості ПЗ (Software Quality Concepts);

- визначення і планування якості (Definition & Planning for Quality);

- техніки й види діяльності, що забезпечують гарантію якості, валідацію і верифікацію (Activities and Techniques for Software Quality Assurance, Validation & Vérification -V&V);

- вимірювання при аналізі якості ПЗ (Measurement in Software Quality Analysis).

Концепція якості ПЗ - це зовнішні і внутрішні характеристики якості, їхні метрики, а також моделі якості, визначені на множині цих характеристик, що наве­дені в стандартах з якості і в [8, 9] - це шість характеристик і кожна з них має кілька атрибутів. До характеристик якості належать:

- функціональність (functionality);

- надійність (reliability);

- зручність застосування (usability);

- ефективність (efficiency);

- супровід (maintainability);

- переносність (portability).

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

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

Планування якості призначено для підтримки керування процесами досяг­нення якості продуктів проекту (зокрема проміжних робочих) і ресурсів - програмних, технічних, виконавських і ін. Воно також передбачає керування ви­могами до процесів і продуктів і полягає в наступному:

- визначення продукту термінами заданими характеристиками якості;

- планування процесів для гарантії одержання необхідної якості;

- вибір методів оцінки запланованих характеристик якості і встановлення відповідності продукту сформульованим вимогам.

У стандарті ISO/IEC 12207 визначені спеціальні процеси забезпечення якості - верифікація, валідація (атестація), спільний аналіз і аудит.

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

Інспекція ПЗ - аналіз і перевірка різних видів подання системи і ПЗ (специфі­кації, архітектурної схеми, діаграм, початкового коду тощо). Виконується на всіх етапах ЖЦ розробки ПЗ.

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

Валідація - процес перевірки відповідності ПЗ функціональним і не функціональним вимог і очікуваним потребам замовника.

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

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

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

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

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

Призначення аудита - незалежна оцінка продуктів і процесів на відповідність регулюючим і регламентуючим документам (планам, стандартам і ін.), формулю­вання звіту про випадки невідповідності і пропозицій для їх коригування.

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

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

Висновки. Запропоновано нове тлумачення програмної інженерії з точки зору науки, інженерії і виробництва. Наведено дефініцію програмної інженерії як спадкоємиці програмування і комп'ютерної науки, розглянуто її головний аспект - керування роботами і колективом. Обґрунтовано теоретичні і прикладні ознаки та атрибути програмної інженерії і її дисциплін. Визначено їхню структуру, зміст та концепції, а також їхні базові елементи. Встановлено зв'язки основних елементів ПІ через SWЕВОК, стандарт ISO/IEС 12207 і РМВОК. Разом вони забезпечують інженерну дисципліну вироблення програмних продуктів на процесах розроблення, керування і регулювання діяльності розробників програмних продуктів.

 

Контрольні питання і завдання

 

1. Назвіть мету і задачі програмної інженерії.

2. Назвіть основні складові наукової дисципліни.

3. Назвіть області знань SWEBOK інженерії розроблення ПЗ.

4. Назвіть основні задачі області інженерії вимог.

5. Назвіть основні задачі області знань «Проектування ПЗ»

6. Визначте мету і задачі області знань «Методи і інструменти»

7. Наведіть базові поняття області знань «Тестування ПЗ».

8. Визначте мету і задачі області знань «Керування проектом».

9. Наведіть приклади інструментів програмної інженерії.

10. Визначте мету і задачі області знань «Інженерія якості ПЗ».

11. Вкажіть, який зв'язок існує між ядром знань SWEBOK і стандартом ЖЦ.

12. Охарактеризуйте інфраструктуру програмної інженерії.

 

2. Характеристика життєвого циклу стандарта ISO/IEC 12207.

 

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

Стандарт ISO/IEC 12207:2002 визначає загальну структуру і зміст ЖЦ ПС, по­чинаючи з розробки концепції до утилізації системи. Структурно він складається з опису багатьох процесів, взаємозв'язків між ними, а також сформульованих дій і задач, виконуваних у цих процесах. Іншими словами, стандартний життєвий цикл визначає лише схему робіт за процесами розробки ПС, а не те, як саме виконувати ті або інші процеси (табл.2.1).

Стандарт не зобов'язує використовувати всі процеси ЖЦ одночасно і не ста­вить особливих вимог до формату і змісту розроблених документів. Тому організація-користувач стандарту під час розроблення конкретного програмного продукту може створити стандарти підприємства, методики і процедури, що деталізувати­муть вибрані для конкретних потреб процеси ЖЦ. Міжнародна організація зі стандартизації ISO (International Organization for Standardization) випускає також посібники і настанови, що доповнюють стандарт ISO/IEC 12207.

Як видно з табл. 2.1. усі процеси в даному стандарті поділяються на три кате­горії:

- основні процеси: процеси підтримки;

- організаційні процеси.

Для кожного з процесів визначені виш діяльності (дії - activity), задачі, суку­пність результатів (виходів) діяльності і розв'язання задач, а також деякі специфічні вимоги. У стандарті наведено перелік робіт для основних, організаційних процесія і процесів підтримки, але не спосіб їх виконання і не форма поданім результатів.

У стандарті до основних процесів належать:

- процес придбання, який ініціює ЖЦ ПС і визначає дії організації-покупця (або замовника) що отримує автоматизовану систему або сервіс. Цей процес містить у собі так і види діяльності: ініціювання і підготовка запиту, оформлення контракту і Його актуалізація; моніторинг користувачів, при­ймання і завершення;

- процес постачання, який визначає дії з передачі покупцю програмного про­дукту або сервісу і містить у собі такі види діяльності: підготовку пропозицій (від­повідей на запити), оформлення контракту, планування, виконання і контроль про, що повідомляє, аналіз і оцінку продукту; постачання і завершення робіт і постачання. Процес постачання

Таблиця 2.1. Процеси життєвого циклу в стандарті ISO/IEC 12207

 

№ п/п Процес (під процес)
1. Категорія «Основні процеси»
1.1	Замовлення (договір)
1.1.1	Підготовка замовлення, вибір постачальника
1.1.2	Моніторинг діяльності постачальника, приймання споживачем
1.2	Постачання (придбання)
1.3	Розроблення
1.3.1	Виявлення вимог
1.3.2	Аналіз вимог до системи
1.3.3	Проектування архітектури системи
1.3.4	Аналіз вимог до ПЗ системи
1.3.5	Проектування ПЗ
1.3.6	Конструювання (кодування) ПЗ
1.3.7	Інтеграція ПЗ
1.3.8	Тестування ПЗ
1.3.9	Системна інтеграція
1.3.10	Системне тестування
1.3.11	Інсталяція ПЗ
1.4	Експлуатація
1.4.1	Функціональне використання
1.4.2	Підтримка споживача
1.5	Супроводження
2. Категорія «Процеси підтримки»
2.1	Документування
2.2	Керування конфігурацією
2.3	Забезпечення гарантії якості
2.4	Верифікація
2.5	Валідація
2.6	Загальний огляд
2.7	Аудит
2.8	Вирішення проблем
2.9	Забезпечення застосовності продукту
2.10	Оцінювання продукту
	3. Категорія «Організаційні процеси »
	3.1 Керування
	3.1.1	Керування на рівні організації
	3.1.2	Керування проектом
	3.1.3	Керування якістю
	3.1.4	Керування ризиком
	3.1.5
	3.1 6	Вимірювання
		Керування знаннями
	3.2 Удосконалення
	3.2.1	Упровадження процесів
	3.2.2	Оцінювання процесів
	3.2.3	Удосконалення процесів

 

 

починається тоді, коли встановлені договірні відношення між замовником і постачальником. Залежно від умов договору процес постачання може містити у собі процес розроблення ПЗ, процес експлуатації і супроводження для виправлення і поліпшення 11С;

- процес розроблення, який визначає дії підприємства-розробника програмного продукту: аналіз вимог до системи; проектування архітектури системи, детальне проектування компонентів ПС, кодування і тестування ПС, інтеграцію системи, кваліфікаційне тестування, установку ПС і забезпечення приймання ПС (рис.2.3);

 

Рис. 2.1. Схема основних процесів ЖЦ ПС

 

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

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

До категорії основних процесів належать також «первинні» процеси, що визначають порядок підготовки договору на розробку ПС, моніторинг діяльності постачальників ПС тощо (див. табл.2.1).

 

Рис. 2.2. Схема допоміжних процесів ЖЦ ПС

 

Стандарт містить у собі опис допоміжних процесів, що регламентують додаткові дії з перевірки продукту, керування проектом та його якістю (рис.2.2).

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

До організаційних процесів належать: керування проектом (менеджмент розробки), якістю, ризиками тощо. Ці процеси виконуються спеціальними служба­ми, що здійснюють планування робіт у проекті, контроль процесів, визначення мет­рик для вимірювання продуктів, перевірку показників якості, дотримання стандартних положень та ін.

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

Процеси керування в стандарті структуровані за рівнями і напрямами, вони жодним чином не зв'язані з існуючими методами і засобами програмної інженерії з розроблення ПС. Це дає можливість при їх виборі для застосування у ЖЦ зіставляти з ними звичні парадигми і методи розроблення (об'єктні, компонентні, сервісні й ін.) та засоби ядра знань SWЕВОК.

Таким чином, між стандартом ISO/IEC 12207 і ядром знань SWЕВОК існує зв'язок: вони взаємодоповнюють та збагачують один одного, більше у розробці відповідних документів орали участь одні ті самі висококваліфіковані фахівці в галузі програмування й інформатики. Інженерна дисципліна проектування ПС використовує теоретичні, прикладні методи і засоби розробки ПС і стандарти (ISO/IEC 12207, ISO/IEC 15404, ISO/IEC 9126 та ін.), а також рекомендації і мето­дики керування розробкою, до яких відносять методи оцінки на процесах ЖЦ, якості ПС, витрачених ресурсів і вартості виконаних робіт. При цьому ядро знань SWEВОК, а також численні монографії і статті рекомендують до застосування методи і засоби програмної інженерії, а стандарт дає настанови до побудови процесів на стандартизованій інженерній основі.

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

Контрольні питання і завдання

 

1. Назвіть мету і задачі програмної інженерії.

2. Назвіть основні складові наукової дисципліни.

3. Назвіть області знань SWEBOK інженерії розроблення ПЗ.