2.4. Каскадна модель
У ранніх не дуже великих за обсягом однорідних ІС кожен додаток являв собою єдине ціле. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (рис. 2.1.). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників. Позитивні сторони застосування каскадного підходу полягають в наступному [5]:
на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти та узгодженості;
виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.
Рис. 2.1. Каскадна схема розробки
Каскадний підхід добре зарекомендував себе при побудові ІС, для яких на самому початку розробки можна досить точно і повно сформулювати всі вимоги, з тим, щоб надати розробникам свободу реалізувати їх якнайкраще з технічної точки зору. У цю категорію потрапляють складні розрахункові системи, системи реального часу та інші подібні завдання. Проте в процесі використання цього підходу виявився ряд його недоліків, спричинених насамперед тим, що реальний процес створення систем ніколи повністю не вкладався в таку жорстку схему. В процесі створення постійно виникала потреба в поверненні до попередніх етапів і уточнення або перегляд раніше прийнятих рішень. У результаті реальний процес створення ПЗ приймав такий вигляд:
Рис. 2.2. Реальний процес розробки ПЗ за каскадною схемою
Основним недоліком каскадного підходу є суттєве запізнення з отриманням результатів. Узгодження результатів з користувачами проводиться тільки в точках, що плануються після завершення кожного етапу робіт, вимоги до ІС «заморожені» у вигляді технічного завдання на весь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена. У разі неточного викладу вимог або їх зміни протягом тривалого періоду створення ПЗ, користувачі отримують систему, яка не задовольняє їх потребам. Моделі (як функціональні, так й інформаційні) об'єкта, що автоматизується, можуть застаріти одночасно з їх затвердженням. Сутність системного підходу до розробки ІС полягає в її декомпозиції (розбитті) на функції, що автоматизуються: система розбивається на функціональні підсистеми, які в свою чергу діляться на підфункції, що підрозділяються на завдання і так далі. Процес розбиття триває аж до конкретних процедур. При цьому система, що автоматизується, зберігає цілісне уявлення, в якому всі складові компоненти взаємопов'язані. Таким чином, дана модель має головну перевагу - системність розробки, а основний недолік - повільно і дорого.
2.5. Спіральна модель
Для подолання перелічених проблем була запропонована спіральна модель ЖЦ [4] (рис. 2.3.), що спирається на початкові етапи ЖЦ: аналіз та проектування. На цих етапах реалізовуємість технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Таким чином, поглиблюються і послідовно конкретизуються деталі проекту і в результаті вибирається обгрунтований варіант, який доводиться до реалізації.
Розробка ітераціями відображає об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не чекаючи повного завершення роботи на поточному. При ітеративному способі розробки відсутню роботу можна буде виконати на наступній ітерації. Головне ж завдання - якнайшвидше показати користувачам системи працездатний продукт, тим самим, активізуючи процес уточнення і доповнення вимог. Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її вирішення необхідно ввести тимчасові обмеження на кожен з етапів життєвого циклу. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, отриманих в попередніх проектах, і особистого досвіду розробників.
Рис. 2.3. Спіральна модель ЖЦ ІС
Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ, отримала останнім часом широкого поширення методологія швидкої розробки додатків Rapid Application Development (RAD). Під цим терміном зазвичай розуміється процес розробки ПЗ, що містить 3 елементи:
невелику команду програмістів (від 2 до 10 осіб);
короткий, але ретельно пророблений виробничий графік (від 2 до 6 місяців);
повторюваний цикл, при якому розробники, у міру того, як додаток починає набувати форму, запитують і реалізують в продукті вимоги, отримані через взаємодію із замовником.
Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:
фаза визначення вимог і аналізу;
фаза проектування;
фаза реалізації;
фаза впровадження.
Послідовність етапів створення ІС на фазі визначення вимог і аналізу:
Опис предметної області, структура організації, завдання, які вирішуються підрозділами, DFD для існуючої інформаційної технології.
Призначення ІС.
Побудова початкової контекстної діаграми потоків даних (DFD).
Формування матриці списку подій (ELM) і таблиці потоків даних.
Побудова ієрархії контекстних діаграм.
Діаграма структур даних.
На стадії проектування ІС моделі розширюються, уточнюються і доповнюються діаграмами, що відображають структуру програмного забезпечення: архітектуру ПЗ, структурні схеми програм і діаграми екранних форм. Результатами проектування архітектури є:
модель процесів (діаграми архітектури системи (SAD) і мініспецифікації структурованою мовою);
модель даних (ERD і підсхеми ERD);
модель користувацького інтерфейсу (класифікація процесів на інтерактивні та неінтерактивні функції, діаграма послідовності форм (FSD - Form Sequence Diagram), що показує, які форми з'являються в додатку і в якому порядку. На FSD фіксується набір і структура викликів екранних форм. Діаграми FSD утворюють ієрархію, на вершині якої знаходиться головна форма програми, що реалізує підсистему. На другому рівні знаходяться форми, що реалізують процеси нижнього рівня функціональної структури, зафіксованої на діаграмах SAD.