6. Модель швидкої розробки додатків (Rapid Application Development).

Модель швидкої розробки додатків (Rapid Application Development) – приклад інкрементної стратегії конструювання.

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

RAD – підхід орієнтований на розробку інформаційних систем та виділено наступні етапи:

• Бізнес – моделювання. Моделюється інформаційний потік між бізнес – функціями. Шукається відповідь на наступні запитання: Яка інформація керує бізнес – процесом? Яка інформація генерується? Хто її генерує? Де інформація застосовується? Хто її обробляє?

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

• Моделювання обробки. Визначаються перетворення об’єктів даних, що забезпечують реалізацію бізнес – функцій. Створюються описи обробки для додавання, модифікації, видалення чи знаходження (виправлення) об’єктів даних.

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

• Тестування та поєднання. Оскільки застосовуються програмні компоненти, що використовуються повторно, то багато програмних елементів вже протестовано. Це зменшує час тестування (оча всі нові елементи повинні бути протестовані).

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

Недоліки та обмеження RAD:

• Для великих проектів у RAD потрібні суттєві людські ресурси (необхідно створити достатню кількість груп).

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

• RAD не застосовується в умовах високих технічних ризиків (тобто при використанні нової технології).

7. Екстремальне програмування xp

Екстремальне програмування (eXtreme Programming, XP) – полегшений (рухомий) процес (методологія), головний автор Кент Бек (1999). ХР – процес орієнтований на групи малого та середнього розмірів, що будують програмне забезпечення в умовах невизначених вимог чи вимог, що швидко змінюються. ХР – групу утворюють до 10 співробітників, які розміщуються в одному приміщенні.

Основна мета ХР – ліквідувати високу вартість змін. ХР – група має справу зі змінами вимог на протязі всього ітераційного циклу розробки, причому цикл складається з дуже коротких ітерацій.

Чотири базові дії:

• Кодування;

• Тестування;

• Вислуховування замовника;

• Проектування.

Динамізм забезпечується за допомогою чотирьох характеристик:

• Неперервний зв’язок з замовником (та у групі);

• Простота (завжди приймається мінімальне рішення);

• Швидкий обернений зв’язок (за допомогою модульного та функціонального тестування;

• Сміливість у проведенні профілактики можливих проблем.

Більшість принципів, що підтримуються в ХР (мінімальність, простота, еволюційний цикл розробки, мала продовжуваність ітерацій, участь користувача, оптимальні стандарти кодування і т.д.), продиктовані здоровим глуздом та використовуються в будь – якому впорядкованому процесі. Просто в ХР ці принципи приймають екстремальних значень(див. табл.).

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

ХР – строго впорядкований процес.

Базис ХР складають наступні 12 методів:

1. Гра планування (planning game) – швидке визначення області дій наступної реалізації шляхом об’єднання ділових пріоритетів та технічних оцінок. Замовник формує область дій, пріоритетність та строки з точки зору бізнесу, а розробники оцінюють та спостерігають просування (прогрес).

2. Часта зміна версій (small releases) – швидкий запуск у виробництво простої системи. Нові версії реалізуються в дуже короткому (двотижневому) циклі.

3. Метафора (metaphor) – вся розробка проводиться на основі простої, загальнодоступної історії про те, як працює вся система.

4. Просте проектування (simple design) – проектування виконується настільки просто, наскільки можливо у даний момент.

5. Тестування (testing) – неперервне написання тестів для модулів, які повинні виконуватися бездоганно; замовники пишуть тести для демонстрації закінченості функцій.

6. Реорганізація ( refactoring) – система реконструюється, але її поведінка не змінюється; мета – позбутися дублювання, покращити взаємодію, спростити систему чи додати їй гнучкості.

7. Парне програмування (pair programming) – весь код пишеться двома програмістами, що працюють на одному комп’ютері.

8. Колективне володіння кодом (collective ownership) – будь-який розробник може покращити будь-який код системи в будь-який час.

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

10. 40-годинний тиждень (40-hour week) – як правило, працюють не більше 40 годин на тиждень. Не можна подвоювати робочий тиждень за рахунок понаднормових робіт.

11. Локальний замовник (on-site customer) – в групі весь час повинен знаходитися представник замовника, дійсно готовий відповідати на питання розробників.

12. Стандарти кодування (coding standards) – повинні дотримуватися правила, що забезпечують однакове представлення програмного коду у всіх частинах програмної системи.

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

Метафора забезпечує глобальне “бачення” проекту. ХР пропонує неперервне перепроектування (за допомогою реорганізації), при якому немає потреби в деталізованій проектній документації, а для інженерів єдиним надійним джерелом інформації являється програмний код. Зазвичай після написання коду проектна документація викидається. Проектна документація зберігається лише в тому випадку, коли замовник на деякий час губить здатність придумувати нові історії. Тоді систему поміщають у “нафталін” та пишуть керівництво на 5 – 10 сторінок по “нафталіновому” варіанту системи. Використання реорганізації приводить до реалізації найпростішого рішення, що задовольняє поточним потребам. Зміни у вимогах заставляють відмовлятися від всіх “загальних рішень”.

Парне програмування – один з найбільш спірних методів у ХР, воно впливає на ресурси, що дуже важливо для менеджерів, що вирішують, чи буде проект використовувати ХР. Може здатися, що парне програмування подвоює ресурси, але дослідження довели: парне програмування приводить до підвищення якості та зменшенню часу циклу. Для узгодженої групи затрати збільшуються на 15%, а час циклу скорочується на 40 – 50%. Для Інтернет – середовища збільшення швидкості продаж покриває підвищення затрат.

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

“тестуй, а потім кодуй!” – ця фраза виражає акцент ХР на тестуванні. Вона відображує принцип, по якому спочатку планується тестування, а тестові варіанти розробляються паралельно аналізу вимог.

Основним засобом ХР є метрика, а середовище метрик – “велика візуальна діаграма”. Зазвичай використовують 3 – 4 метрики, що бачить вся група. Рекомендованою в ХР метрикою є “швидкість проекту” – кількість історій заданого розміру, які можуть бути реалізовані в ітерації.

При прийнятті ХР рекомендується освоювати його методи по одному, кожний раз обираючи метод, орієнтований на найважчу проблему групи. Звичайно всі ці методи є “не більше ніж правилами” – група може в будь-який момент змінити їх (якщо її співробітники досягли згоди щодо внесених змін).

Розглянемо структуру “ідеального” ХР – процесу. Основним структурним елементом процесу є ХР – реалізація, в яку багаторазово вкладається базовий елемент – ХР – ітерація. У склад ХР – процесу та ХР – ітерації входять три фази – дослідження, блокування, регулювання. Дослідження –це пошук нових вимог (історій, задач), які повинна виконувати система. Блокування – вибір для реалізації конкретної підмножини з всіх можливих вимог (іншими словами, планування). Регулювання – проведення розробки, втілювання плану в життя.

ХР рекомендує: перша реалізація повинна мати тривалість 2 – 6 місяців, тривалість інших реалізацій – близько двох місяців, кожна ітерація триває 2 тижні, а чисельність групи розробників не перевищує 10 чоловік.