Спіральна модель процесу розробки інформаційних систем

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

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

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

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

Фактично традиційна каскадна модель має відповісти на два запитання:

1)    що має бути зроблене наступним?

2)    як довго воно має тривати?

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

На рис. 4.2 представлена оригінальна діаграма спіральної моделі, розроблена у 1988 р. американським вченим Б. Боемом. Особливість даної діаграми полягає в тому, що вона сфокусована на питаннях проектування. Для комплексних проектів використовується модифікований варіант діаграми, що більше уваги приділяє іншим етапам розробки інформаційної системи.

Рисунок 4.2 – Оригінальна діаграма спірального розвитку

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

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

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

Лише завдяки створенню прототипу інтерфейсу користувача дослідним шляхом було встановлено, що вимога щодо часу реакції системи на дії користувача, який не повинен перевищувати однієї секунди, є завищеною, і достатньо затримки до чотирьох секунд. В результаті переробки вимог оціночна вартість системи була знижена до 30 млн. дол. США (рис. 4.3).

На рис. 4.3 зображено дві можливі архітектури побудови системи. Кожна з них має свою сферу застосування: архітектура А здатна забезпечити більш високу швидкість реакції системи, проте архітектура В за умов невисоких вимог до швидкості реакції має значно нижчу вартість реалізації.

Рисунок 4.3 – Два проекти системи: затрати у порівнянні з часом реакції

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

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

Головні переваги використання спіральної моделі полягають у наступному:

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

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

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

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

•    значно спрощується випуск послідовних версій продукту;

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