Мал. 5. Розробка ПЗ з повторним використанням раніше створених компонентів

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

Ітераційні моделі розробки ПЗ

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

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

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

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

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