Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /home/qalight/qalight.com.ua/lviv/wp-includes/plugin.php on line 601

Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given in /home/qalight/qalight.com.ua/lviv/wp-includes/plugin.php on line 601
Інкрементна модель (Incremental model) - QALight

База знань

Інкрементна модель (Incremental model)

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

Наприклад, ПЗ для обробки слів в 1-му Інкременті (версії) реалізує функції базової обробки файлів, функції редагування та документування; у 2-му Інкременті – більш складні можливості редагування та документування; в 3-му Інкременті – перевірку орфографії і граматики; в 4-му Інкременті – можливості компонування сторінки. Перший інкремент призводить до отримання базового продукту, реалізує базові вимоги (правда, багато допоміжні вимоги залишаються нереалізованими). План наступного інкремента передбачає модифікацію базового продукту, що забезпечує додаткові характеристики і функціональність. За своєю природою інкрементний процес ітеративний, але, на відміну від макетування, інкрементна модель забезпечує на кожному Інкременті працюючий продукт. Нові дані виходять як в ході розробки ПЗ, так і в ході його використання, де це можливо.

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

Для організації інкрементної розробки зазвичай вибирається характерний часовий інтервал, наприклад тиждень. Потім протягом цього інтервалу відбувається оновлення проекту: додається нова документація як текстова, так і графічна (наприклад, нові діаграми на UML), розширюється набір тестів, додаються нові програмні коди і т. д. Теоретично кроки розробки (increments) можуть виконуватися і паралельно, але такий процес дуже складно скоординувати. Інкрементна розробка проходить найкраще, якщо наступна ітерація n + 1 починається після того, як оновлення всіх артефактів в ітерації n закінчено, та істотно гірше, якщо час, необхідний на оновлення артефактів, значно перевищує обраний інтервал.

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

 

Набагато більше інформації на курсі базовий модуль тестування