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

Розглянемо особливості традиційної моделі процесу розробки інформаційної системи.

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

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

Традиційна модель процесу розробки інформаційних систем стала результатом певної схожості звичайної інженерно-конструкторської діяльності з процесом розробки програмного забезпечення.

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

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

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

Основні недоліки каскадної моделі:

•    після випуску продукту проект завершується. Зміни продукту – це новий продукт (і, отже, новий проект). Логічний наслідок: усі завдання повинні бути зробленими відразу, якщо ж щось зразу не зроблене, то це є недоліком продукту;

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

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

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