3. Стратегії конструювання програмного забезпечення.

Існує три стратегії конструювання ПЗ:

• одноразовий підхід (водоспадна стратегія) – лінійна послідовність етапів конструювання;

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

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

Характеристики стратегій конструювання ПЗ у відповідності до стандарту IEEE/EIA 12207.2 наступні:

Стратегія конструювання	На початку процесу визначені всі вимоги?	Багато циклів конструювання?	Проміжне ПЗ розповсюджується?
одноразовий підхід	Так	Ні	Ні
інкрементна стратегія (заплановане поліпшення продукту)	Так	Так	Можливо
еволюційна стратегія	Ні	Так	Так

4. Інкрементна модель життєвого циклу.

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

Кожна лінійна послідовність тут виробляє інкремент ПЗ, що постачається.

Кожний інкремент складається з наступних етапів:

1. аналіз;

2. проектування;

3. кодування;

4. тестування.

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

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

Відмінність від макетування заключається в тому, що модель забезпечує на кожному інкременті продукт що працює.

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

5. Спіральна модель життєвого циклу програмного продукту.

Спіральна модель – класичний приклад застосування еволюційної стратегії.

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

1 – початковий збір вимог та планування проекту;

2 – та ж робота, але на основі рекомендацій замовника;

3 – аналіз ризику на основі початкових вимог;

4 – аналіз ризику на основі реакцій замовника;

5 – перехід до комплексної системи;

6 – початковий макет системи;

7 – наступний рівень макету;

8 – сконструйована система;

9 – оцінювання замовником.

Модель визначає чотири дії:

• Планування – визначення мети, варіантів та обмежень.

• Аналіз ризику – аналіз варіантів та розпізнання/вибір ризику.

• Конструювання – розробка продукту наступного рівня.

• Оцінювання – оцінка замовником поточних результатів конструювання.

З кожною ітерацією по спіралі (рух від центру до периферії) будуються все більш повні версії ПЗ.

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

Переваги спіральної моделі:

1. найбільш реально (у вигляді еволюції) відображує розробку ПЗ;

2. дозволяє явно враховувати ризик на кожному витку еволюції розробки;

3. включає крок ітераційного підходу в ітераційну структуру розробки;

4. використовує моделювання для зменшення ризику та вдосконалення програмного виробу.

Недоліки спіральної моделі:

1. новизна (відсутня достатня статистика ефективності моделі);

2. підвищені вимоги до замовника;

3. труднощі контролю та керування часом розробки.