12

1. Методологія RAD

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є що одержала останнім часом широке розповсюдження методологія швидкої розробки застосувань RAD (Rapid Application Development). Під цим терміном звичайно розуміється процес розробки ПЗ, що містить 3 елементи:

* невелику команду програмістів (від 2 до 10 чоловік);

* короткий, але такий, що ретельно пропрацював виробничий графік (від 2 до 6 міс.);

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

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

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

* фаза аналізу і планування вимог;

* фаза проектування;

* фаза побудови;

* фаза впровадження.

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

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

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

* загальна інформаційна модель системи;

* функціональні моделі системи в цілому і підсистем, розробників, що реалізовуються окремими командами;

* точно визначені за допомогою CASE-засобу інтерфейси між підсистемами, що автономно розробляються;

* побудовані прототипи екранів, звітів, діалогів.

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

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

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

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

* визначається необхідність розподілу даних;

* проводиться аналіз використання даних;

* проводиться фізичне проектування бази даних;

* визначаються вимоги до апаратних ресурсів;

* визначаються способи збільшення продуктивності;

* завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всім узгодженим вимогам.

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

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

Методологія RAD непридатна для побудови складних розрахункових програм, операційних систем або програм управління космічними кораблями, тобто програм, що вимагають написання великого об'єму (сотні тисяч рядків) унікального коду.

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

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

Як підсумок перерахуємо основні принципи методології RAD:

* розробка застосувань ітераціями;

* необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

* обов'язкове залучення користувачів в процес розробки ІС;

* необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

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

* необхідне використання генераторів коду;

* використання прототипування, що дозволяє повніше з'ясувати і задовольнити потреби кінцевого користувача;

* тестування і розвиток проекту, здійснювані одночасно з розробкою;

* ведення розробки нечисленною добре керованою командою професіоналів;

* грамотне керівництво розробкою системи, чітке планування і контроль виконання робіт.

2. Моделювання даних

Case-метод Баркера

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

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

Нотація ERD була вперше введена П. Ченом (Chen) і одержала подальший розвиток в роботах Баркера. Метод Баркера висловлюватиметься на прикладі моделювання діяльності компанії по торгівлі автомобілями. Нижче приведені витяги з інтерв'ю, проведеного з персоналом компанії.

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

Продавець: йому потрібно знати, яку ціну запрошувати і яка нижня ціна, за яку можна зробити операцію. Крім того, йому потрібна основна інформація про машини: рік випуску, марка, модель і т. п.

Адміністратор: його завдання зводиться до складання контрактів, для чого потрібна інформація про покупця, автомашину і продавця, оскільки саме контракти приносять продавцям винагороди за продажу.

Перший крок моделювання - витягання інформації з інтерв'ю і виділення суті.

Суть (Entity) - реальний або уявний об'єкт, що має істотне значення для даної наочної області, інформація про яке підлягає зберіганню

3. Організація проекту