2. Ітераційні моделі розробки пз

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

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

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

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

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

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

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

Рис. 1.6. Модель покрокової розробки

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

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

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

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

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

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

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

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

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

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

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

Спіральна модель розробки

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

Кожний виток спіралі розбитий на чотири сектори.

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

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

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

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

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

Рис. 1.7. Спіральна модель створення ПЗ

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

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