1.4.2 Ітеративна модель
Ітеративна модель передбачає розбиття життєвого циклу проекту на послідовність ітерацій, кожна з яких нагадує "міні-проект", включаючи всі фази життєвого циклу в застосуванні до створення менших фрагментів функціональності, порівняно з проектом в цілому. Мета кожної ітерації - отримання працюючої версії програмної системи, що включає функціональність, визначену інтегрованим змістом всіх попередніх та поточної ітерації. Така система розробки дозволяє мінімізувати всілякі ризики, пов'язані з впровадженням нових технологій, зміною вимог до проекту, просто невірним кодом.
Існує два види ітеративної моделі: спіральна та інкрементальна.
В разі спірального процесу послідовність «аналіз вимог – проектування – реалізація – інтеграція - тестування» виконується більше, ніж один раз. Причинами цього є: необхідність запобігання ризиків та необхідність надати замовникові часткову версію проекту для отримання відгуків і побажань. Загальна ідея спірального процесу полягає в тому, щоб на кожній ітерації будувати чергову версію програми, використовуючи як основу її попередню версію. В цьому випадку процес набуває спіралевидний характер.
Рисунок 1.3 – Спіральна модель розробки програмного забезпечення
Спіральна модель має такі переваги:
-
Модель приділяє спеціальну увагу ранньому аналізу можливостей повторного використання. Це забезпечується, в першу чергу, в процесі ідентифікації і оцінки альтернатив.
-
Модель передбачає можливість еволюції життєвого циклу, розвиток і зміну програмного продукту. Головні джерела змін поміщені в цілях, для досягнення яких створюється продукт.
-
Модель надає механізми досягнення необхідних параметрів якості як складову частину процесу розробки програмного продукту. Ці механізми будуються на основі ідентифікації всіх типів цілей (вимог) і обмежень на всіх «циклах» спіралі розробки.
-
Модель приділяє спеціальну увагу запобіганню помилок і відкиданню непотрібних, необґрунтованих або незадовільних альтернатив на ранніх етапах проекту. Це досягається явно певними роботами по аналізу ризиків, перевірці різних характеристик створюваного продукту (включаючи архітектуру, відповідність вимогам і тому подібне) і підтвердження можливості рухатися далі на кожному «циклі» процесу розробки.
-
Модель дозволяє контролювати джерела проектних робіт і відповідних витрат.
-
Модель, орієнтована на ризики, дозволяє в контексті конкретного проекту вирішити завдання додатка адекватного рівня зусиль, що визначається рівнем ризиків, пов'язаних з недостатнім виконанням тих або інших робіт.
-
Модель не проводить відмінностей між розробкою нового продукту і розширенням того, що існує. Цей аспект дозволяє уникнути відношення, що часто зустрічається, до підтримки і супроводу як до «другосортної» діяльності.
-
Модель дозволяє вирішувати інтегровані завдання системної розробки, що охоплює і програмну і апаратну складові створюваного продукту. Підхід, заснований на управлінні ризиками і можливості своєчасного відкидання непривабливих альтернатив (на ранніх стадіях проекту) скорочує витрати і однаково застосовується і до апаратної частини, і до програмного забезпечення.
Хоча спіральна модель відображає типову схему процесу розробки, вона вимагає майстернішого управління, ніж проста модель водопаду. Одна з труднощів полягає в підтримці цілісності документації, яка має бути повністю оновлена і доповнена до кінця кожної ітерації. Управління документацією ще більш ускладнюється, коли з метою підвищення продуктивності команди чергова ітерація процесу починається до завершення попередньої ітерації.
Інкрементальна модель відповідає випадку, коли число ітерацій зростає настільки, що кожна нова ітерація надає дуже малу кількість нових можливостей в порівнянні з попередніми. Дана модель корисна на пізніх стадіях проекту, коли продукт знаходиться на супроводі або коли він схожий із створеним раніше.
Для організації інкрементальної розробки зазвичай вибирається характерний часовий інтервал. Потім протягом цього інтервалу відбувається оновлення вихідного проекту. Інкрементальна розробка проходить краще всього, якщо наступна стадія починається по можливості після того, як оновлення всіх модулів на попередній стадії закінчене, і найгірше, якщо час, потрібний на оновлення модулів, значно перевищує вибраний інтервал [9].
Рисунок 1.4 – Інкрементальна модель розробки програмного забезпечення