Мал. 6. Модель покрокової розробки

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

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

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

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

Процес покрокової розробки має цілий ряд переваг.

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

2. Замовник може використовувати компоненти, отримані на перших кроках розробки, як прототипи і провести з ними експерименти для уточнення вимог до тих компонентів, які будуть розроблятися пізніше.

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

4. Оскільки системні сервіси з високим пріоритетом розробляються першими, а всі наступні компоненти інтегруються з ними, неминуче виходить так, що найбільш важливі підсистеми піддаються більш ретельному всебічному тестуванню та перевірці. Це значно знижує ймовірність програмних помилок в особливо важливих частинах системи.

Разом з тим при реалізації покрокової розробки можуть виникнути певні проблеми. Компоненти, одержувані на кожному кроці розробки, мають відносно невеликий розмір (звичайно не більше 20 000 рядків коду), але повинні реалізувати яку-небудь системну функцію. Відобразити безліч системних вимог до компонентів потрібного розміру досить складно. Більш того, багато системи повинні мати набором базових системних властивостей, які реалізуються спільно різними частинами системи. Оскільки вимоги детально не визначені до тих пір, поки не будуть розроблені всі компоненти, буває вельми складно розподілити загальносистемні функції по компонентах.

В даний час запропонований метод так званого екстремального програмування (extreme programming), який усуває деякі недоліки методу покрокової розробки. Цей метод заснований на покрокової розробці малих програмних компонентів, що реалізують невеликі функціональні вимоги, постійному залученні замовника в процес розробки та знеособленому програмуванні (див. Главу 23). У статті [31] описаний метод екстремального програмування і наведено кілька звітів про його успішне застосування, проте подібні звіти можна привести для всіх основних методів розробки ПЗ.