Читайте также: |
|
У найперших однорідних інформаційних системах кожен додаток являло собою єдине ціле. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (рис. 1.1). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Позитивні сторони використання каскадного підходу полягають в наступному:
· на кожному етапі формується закінчений набір проектної документації, який відповідає критеріям повноти та узгодженості;
· виконуються в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Рис. 1.1 Каскадна схема розробки ПЗ
Каскадний підхід добре зарекомендував себе при побудові інформаційних систем, для яких на самому початку розробки можна досить точно і повно сформулювати всі вимоги, з тим, щоб надати розробникам свободу реалізувати їх якомога краще з технічної точки зору.
Проте, в процесі використання цього підходу виявився ряд його недоліків, викликаних перш за все тим, що реальний процес створення ПЗ ніколи повністю не вкладався в таку жорстку схему. У процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапах і уточнення або перегляд раніше прийнятих рішень. У результаті реальний процес створення ПЗ брав наступний вигляд (рис. 1.2):
Рис. 1.2 Реальний процес розробки програмного забезпечення по каскадної схемою
Основним недоліком каскадного підходу є істотне запізнювання з отриманням результатів. Узгодження результатів з користувачами проводиться тільки в точках, планованих після завершення кожного етапу робіт, вимоги до ІС «заморожені» у вигляді технічного завдання на весь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена. У разі неточного викладу вимог або їх зміни протягом тривалого періоду створення ПЗ, користувачі отримують систему, не задовольняє їхніх потреб. Моделі (як функціональні, так і інформаційні) об'єкта, що автоматизується можуть застаріти одночасно з їх затвердженням.
Для подолання перелічених проблем була запропонована спіральна модель ЖЦ (рис. 1.3), що робить упор на початкові етапи ЖЦ: аналіз та проектування. На цих етапах реалізованість технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Таким чином, поглиблюються і послідовно конкретизуються деталі проекту і в результаті вибирається обгрунтований варіант, який доводиться до реалізації.
Розробка ітерації відображає об'єктивно існуючий спіральний цикл створення системи. Неповна завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. При ітеративному способі розробки відсутню роботу можна буде виконати на наступній ітерації. Головне ж завдання - якнайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення та доповнення вимог.
Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її вирішення необхідно ввести тимчасові обмеження на кожен з етапів життєвого циклу. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, отриманих у попередніх проектах, і особистого досвіду розробників.
Рис 1.3 Спіральна модель ЖЦ
Каскадна і галактика моделі встановлюють деякі принципи організаціїжиттєвого циклу створення програмного продукту. Кожна з них має переваги,недоліки і області застосування. Каскадна модель проста, але може бути застосована у випадку,коли вимоги відомі і мінятися не будуть. Спіральна модель враховує такі важливі показники проекту як змінність вимог, неможливість оцінити заздалегідь обсяг фінансування, ризики виконання проекту. Але спіральна модель складна і вимагає великих витрат на супровід.
Існують деякі інші види моделей, які можна розглядати як «Проміжні» між каскадної і спіральної моделями. Ці моделі використовують окремі переваги каскадної і спіральної моделей і досягають успіху для певних типів завдань.
Дата добавления: 2015-07-15; просмотров: 288 | Нарушение авторских прав
<== предыдущая страница | | | следующая страница ==> |
Організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, поліпшення самого ЖЦ, навчання). | | | V-подібна модель |