ОснАлгор_Посібн_Яровенко

2. ВИЗНАЧЕННЯ ТА АНАЛІЗ ВИМОГ ДО ПРОГРАМНОГО ПРОДУКТУ.

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

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

Рис. 10. Модель розробника ПЗ.

Рис. 11. Моделі замовників-користувачів ПЗ.

21

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

2.1. ВАЖЛИВІСТЬ РОБІТ З ВИЗНАЧЕННЯ ВИМОГ ДО ПП.

Як видно з рис. 3-4, перед безпосереднім «написанням» програми (етап «Кодування») розробнику необхідно виконати досить велику кількість дій, об’єднаних в класичній каскадній моделі (рис.2) в два етапи – «Формування вимог» та «Проектування». Важливість цих етапів підкреслюється міжнародними і вітчизняними стандартами, які регламентують їх зміст, а також авторитетними спеціалістами в сфері розробки ПЗ.

Так в дослідженнях американських вчених Standish Group, проведених в 1995-96 роках, серед причин провалів проектів вказуються:

неповнота вимог – 13,1 %;

недостатнє залучення користувачів – 12,4 %;

нереалістичні сподівання – 9,9 %;

зміна вимог/специфікацій – 8,7 %;

недостатнє планування – 8,1 %.

До речі, в звіті згаданої Standish Group за 2006 рік (названий «Хаос» і опублікований 01.03.2007) приведені далекі від втішних результати аналізу декількох десятків тисяч проектів, зв’язаних з розробкою ПЗ. Standish Group констатує (рис.12):

тільки 35% проектів, розпочатих в 2006 році, можуть класифікуватися як успішні, тобто вони були завершені вчасно, в межах запланованого бюджету і згідно вимог користувачів (для порівняння, 1994 рік – 16,2 %);

19% проектів визнані відверто невдалими і були анульовані (1994 р. – 31,1%);

46% проектів або завершились із запізненням, або витрати перевищили запланований бюджет, або не повністю задовольнили потреби користувача

(1994 р. – 53,2%).

60,0%	53,2%	46,0%
50,0%
		35,0%
40,0%	31,1%			Успішні
30,0%	16,2%	19,0%		Відносно успішні
20,0%				Невдалі
10,0%
0,0%	1994	2006

Рис.12. Результати аналізу успішності ІТпроектів

Красномовними та інформативними (хоч і стосуються далекого 1994 р.) є результати досліджень Standish Group в грошовому еквіваленті.

В США щорічно витрачається більше 250 млрд. доларів на розробку ІТпроектів (застосувань в рамках інформаційних технологій) приблизно 175 000

22

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

проектів. Середня вартість проекту для крупної компанії складає 2 322 000 доларів, для середньої – 1 331 000 доларів, для малої – 434 000 доларів. Дослідження Standish Group показали, що 31% проектів буде анульовано до завершення, а витрати 52,7% проектів складуть 189% від запланованих витрат. Американські компанії та урядові установи щорічно витрачають 81 млрд. доларів на програмні проекти, які так і не будуть завершені, та до 82 млрд. дол. на проекти, визнані після реалізації такими, що не відповідають вимогам замовників.

Марвін Зелковіц, Алан Шоу та Джон Геннон в своїй класичній праці «Принципи розробки ПЗ» на етапи «Формування вимог» та «Проектування» відводять 35% часу, необхідного для реалізації всіх етапів розробки ПЗ без врахування етапу експлуатації і супроводу, або 11% з 33% із врахуванням останнього (рис. 13,14).

10%		Аналіз вимог
20%
10%		Визначення специфікацій

	15%		Проектування
25%			Кодування
	20%		Автономне тестування
			Комплексне тестування

Рис. 13. Затрати часу на реалізацію етапів циклу розробки ПЗ (без експлуатації і супроводу).

3%	3% 5%
	7%		Аналіз вимог
			Визначення специфікацій
	8%		Проектування
	7%		Кодування
			Автономне тестування
	67%

Комплексне тестування

Експлуатація і супровід

Рис. 14. Затрати часу на реалізацію етапів циклу розробки ПЗ (з урахуванням етапу експлуатації і супроводу).

23

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

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

Стів Макконнелл відзначає: «Якщо Ви спроектували автомобіль «Понтіак Ацтек», то скільки б Ви його не тестували, він ніколи не перетвориться в «Роллс-Ройс». Ви можете створити самий кращий «Ацтек», але якщо Вам потрібен «Роллс-Ройс», то це потрібно планувати з самого початку».

Вчені з компаній Hewlett-Packard, IBM, Hughes Aircraft, TRW та інших організацій виявили, що «виправлення помилки, допущеної до початку конструювання програми обходиться в 10-100 разів дешевше, ніж її усунення в кінці роботи над проектом, під час тестування ПП чи після його випуску»

(рис.15).

100

80

60

40

20

Аналіз Планування Розробка Стабілізація

Рис. 15. Вартість виправлення невірних проектних рішень на різних етапах.

Фредерік Брукс так охарактеризував роль вимог в розробці ПЗ: «Найсуворіше і єдине правило побудови систем ПЗ – точно вирішити, що будувати. Ніяка інша частина концептуальної роботи не є такою важкою, як вияснення деталей технічних вимог. Ніяка інша частина роботи так не псує результат, якщо вона виконана погано. Помилки ніякого іншого етапу роботи не виправляються так важко».

Відомі вчені Дін Леффінгвелл та Дон Відріг приводять таку оцінку – «помилки у визначенні вимог зумовлюють затрати, які складають 25-40% бюджету проекту в цілому».

Статистика свідчить, що більше 60% помилок у програмах виникає на початкових стадіях розробки. Саме тому вимоги до програми мають бути визначені та проаналізовані на початку розробки ПП. Разом з тим процес визначення вимог повинен бути організований досить гнучко, оскільки на будьякому етапі розробки можуть бути виявлені раніше непередбачені вимоги, що вимагає вносити зміни до проекту. З іншої сторони при визначенні вимог потрібно старатись уникнути «паралічу аналітичного процесу». Тобто, не можна витрачати забагато часу на спроби зробити вимоги ідеальними.

24

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

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

Чудовий приклад необхідності узгодження (врахування) «інтересів» всіх сторін привели в своїй монографії Д.Леффінгвелл та Д.Відріг. Вони відзначають, що при проектування будинку розробник має не тільки врахувати і задовольнити вимоги замовника (безпосереднього користувача), але й узгодити свій проект з органами влади, а також, можливо, з найближчими сусідами. Саме представники влади та майбутні сусіди разом із замовником будуть визначати, чи відповідає проект будинку всім вимогам. Зрозуміло, що важливі зацікавлені особи, такі як представники влади та майбутні сусіди, в даній ситуації не є користувачами. Очевидно також, що їх уявлення про якість будинку можуть суттєво відрізнятись.

2.2.ОСНОВНІ ОЗНАЧЕННЯ І СТАНДАРТИ.

Влітературі приводяться різні означення терміну «вимога». Приведемо приклади деяких:

Вимога – це умова або можливість, якій має відповідати ПС. Вимоги – це твердження про функції й обмеження ПС.

Вимоги – це властивості, які повинен мати ПП, щоб бути цінним для своїх користувачів.

Вимоги – це специфікація того, що і як повинно бути реалізовано.

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

1. Відповідно до міжнародного глосарію з термінології комп’ютерної науки:

Означення. Вимоги – це опис:

1)умов або можливостей, необхідних користувачеві для вирішення поставлених проблем або для досягнення цілей;

2)функцій і обмежень, які повинна мати система або системні компоненти, щоб виконати контракт замовника на розробку;

3)положень і регламенту, встановлених використаними стандартами і відображених у специфікаціях або інших формальних документах на ПС;

4)умов, можливостей і обмежень середовища, необхідних для проектування і виконання системи.

2. В стандарті IEEE Standard Glossary of Software Engineering Terminology

(IEEE Std 610.12-1990) цей термін визначається так:

Означення. Вимоги – це:

1)Умови або можливості, необхідні користувачеві для вирішення проблем чи досягнення цілей;

25

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

2)Умови або можливості, якими має володіти ПС або системні компоненти для того, щоб виконати контракт чи відповідати стандартам, специфікаціям та іншим формальним документам;

3)Документальне подання умов і можливостей для пунктів 1 і 2.

Узагальному випадку під вимогами до ПС розуміють властивості, які повинна мати ця система для виконання запропонованих замовником функцій. Прикладами таких функцій можуть бути бізнес-функції, документообіг, керування даними і структурою інформації, що необхідна для прийняття системних рішень, та ін. У ядрі знань SWEBOK викладено основні концепції й особливості інженерії вимог, які подано на рис. 16.

Розробка вимог

Інженерія		Аналіз		Фіксація		Трасування		Керування
вимог		вимог		вимог		вимог		вимогами
Модель		Техніка		Специфіка-		Перегляд		Керування
процесів ЖЦ		обговорення		ція вимог		вимог		змінами
Тривалість		Визначення		Системати-		Трасування		Зв'язок з
виконавців		вимог		зація вимог		вимог		процесами
Керування		Аналіз		Опис		Валідація		Верифікація
вимогами на
		вимог		документу		вимог		вимог
процесах
ЖЦ
Покращення		Збір вимог		Узгодження		Прото-		Оцінка
якості				документу		типування		якості

Рис. 16. Основні розділи розробки вимог.

Зміст та характеристики вимог до ПЗ регламентуються міжнародними та вітчизняними стандартами, зокрема стандартом IEEE Std 830-1998 (IEEE Recommended Practice for Software Requirements Specifications), схваленим 25

червня 1998 року Радою із стандартів IEEE-SA. В цьому стандарті також приведені рекомендації узгодження із стандартом IEEE/EIA 12207.1-1997. Роботи з вимогами регламентуються також наступними нормативними документами IEEE:

IEEE 1362 «Concept of Operations Document».

IEEE 1233 «Guide for Developing System Requirements Specifications».

IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.121990.

IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.

26

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

Опис усіх видів вимог проводиться з урахуванням стандартів, наприклад, стандарту з якості ISO/IEC ДСТУ 9126 і стандартизованого понятійного і термінологічного довідника.

Визначення (формування) та аналіз вимог до будь-яких систем чи продуктів (в тому числі і програмних), які створюються, є настільки важливим, що сьогодні ці роботи виділились в окрему галузь науки «Управління вимогами».

2.3.КЛАСИФІКАЦІЯ ВИМОГ.

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

Однією з найпоширеніших класифікацій вимог до ПП є наступна:

вимоги користувачів (user requirements) – опис на природній мові функцій, які виконуються ПП, та обмежень, які накладаються на цей ПП. Цей клас вимог ще називають вимогами в області проблем;

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

Віншому підході вимоги до ПП класифікуються так:

функціональні вимоги;

нефункціональні вимоги;

вимоги предметної області.

Останню класифікацію варто розглянути детальніше.

Функціональні вимоги.

Означення. Функціональні вимоги – це опис функцій або сервісів, які повинна виконувати програмна система (програмний засіб чи продукт).

При цьому має бути вказано, як ПС реагує на ті чи інші вхідні дані, як веде себе в певних ситуаціях тощо. Функціональні вимоги є основним, визначальним видом вимог до ПС. Вони регламентують її функціонування або поведінку (behavioral requirements), відповідають на запитання «що має робити ПС» в тих чи інших ситуаціях. Функціональні вимоги визначають основний «фронт робіт» розробника та встановлюють цілі, задачі й сервіси, які мають надаватись ПС замовнику-користувачу і мають бути реалізовані розробником. Зазвичай функціональні вимоги формулюються у вигляді правил поведінки із вказівками типу «має», «повинна (повинен)»: «ПС має забезпечити обчислення суми ряду із заданою точністю», «ПС повинна дозволяти формувати залікові та екзаменаційні відомості» тощо. Іншим способом формулювання функціональних вимог є так названі варіанти використання (uses cases), які будуть розглянуті нижче.

27

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

Нефункціональні вимоги.

Означення. Нефункціональні вимоги – це опис неповедінкових характеристик програмної системи та її оточення.

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

На сьогодні відомо досить багато різних класифікацій нефункціональних вимог до ПС (ПП, ПЗс). Наприклад, Д.Леффінгвелл та Д.Відріг класифікують ці вимоги наступним чином:

практичність (usability);

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

продуктивність (performance);

можливість обслуговування (supportability).

К. Вігерс виділяє такі основні групи нефункціональних вимог:

зовнішні інтерфейси (external interfaces);

атрибути якості (quality attributes);

обмеження (constraints).

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

Означення. Якість програмного забезпечення – це набір властивостей програмного продукту (сервісу або програм), що характеризують його здатність задовольнити встановлені або передбачувані потреби замовника.

Кент Бек (Kent Beck) відзначає, що «розробляти програмне забезпечення дуже непросто, але розробляти якісне програмне забезпечення і при цьому завершувати роботу вчасно – ще складніше».

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

В загальному випадку вимоги до якості ПП регламентуються міжнародними та вітчизняними стандартами (ISO/IEC 25001:2007. Програмна інженерія. Оцінювання і вимоги до якості програмного продукту; ДСТУ ISO/IEC TR 9126. Програмна інженерія. Якість продукту; ДСТУ ISO/IEC 14598. Інформаційні технології. Оцінювання програмного продукту тощо).

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

1.Характеристики:

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

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

28

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

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

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

зручність супроводу (maintainability);

мобільність (portability).

2.Атрибути для кожної характеристики якості, які деталізують різні аспекти конкретної характеристики. Набір атрибутів характеристик якості використовується для оцінки якості.

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

4.Ваги – оцінні елементи метрики, які використовується для оцінки кількісного або якісного значення окремого атрибуту якості ПП.

Ієрархія та зміст рівнів базової моделі якості ПЗ добре ілюструє схема, яку приводить К.Лавріщева (рис. 17).

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

вимоги конфіденційності;

відмовостійкість;

число клієнтів, які мають одночасний доступ до ПС;

вимоги безпеки;

час чекання відповіді на звернення до ПС;

виконавські якості ПС (обмеження щодо ресурсів пам’яті, швидкість реакції на звернення до системи тощо);

Вимоги до предметної області.

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

Ці вимоги можуть бути функціональними і нефункціональними.

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

29

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)

Характеристики Атрибути

Функціональність

Надійність

Якість

програмного продукту

Зручність

застосування

Зручність

супроводу

Ефективність

Мобільність

Рис. 17. Ієрархічна структура моделі якості ПП.

30

Повнота функцій Точність Інтероперабельність Захищеність Узгодженість Завершеність Відмостійкість Відновлюваність Узгодженість Зрозумілість Засоби навчання Привабливість Узгодженість Простота аналізу Простота змін Стабільність Простота тестування Узгодженість Реактивність Застосування ресурсів Узгодженість Простота адаптації Простота Сумісність Замінність Узгодженість

Print to PDF without this message by purchasing novaPDF (http://www.novapdf.com/)