Лекція 3. Організація технологічного процесу розробки ПЗ компоненти, вони застосовуються в проекті і включаються в бібліотеку.

Мал. 1.7. Компонентно-орієнтована модель

Переваги компонентно-орієнтованої моделі:

1)зменшує на 30% час розробки програмного продукту;

2)зменшує вартість програмної розробки до 70%;

3)збільшує в півтора рази продуктивність розробки.

3.“Важкі” і “полегшені” процеси

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

Традиційно для впорядкування і прискорення програмних розробок пропонувалися важкі (heavyweight) процеси, що строго упорядковують. У цих процесах прогнозується весь об'єм майбутніх робіт, тому вони називаються прогнозуючими (predictive) процесами. Порядок, який повинен виконувати при цьому людина-розробник, надзвичайно строгий — «крок управо, крок вліво

— віртуальний розстріл!». Іншими словами, людські слабкості в розрахунок не приймаються, а об'єм необхідної документації здатний відняти спокій і сон у «сумлінного» розробника.

Останніми роками з'явилася група нових, полегшених (lightweight) процесів. Тепер їх називають рухомими (agile) процесами. Вони привабливі відсутністю бюрократизму, характерного для важких (прогнозуючих) процесів. Нові процеси повинні втілити в життя розумний компроміс між дуже строгою дисципліною і повною її відсутністю. Інакше кажучи, порядку в них достатньо для того, щоб отримати розумну віддачу від розробників.

Рухомі процеси вимагають меншого об'єму документації і орієнтовані на людину. У них явно вказано на необхідність використання природних якостей людської натури (а не на застосування дій, направлених наперекір цим якостям). Більш того, рухомі процеси враховують особливості сучасного замовника, а саме часті зміни його вимог до програмного продукту. Відомо, що для прогнозуючих процесів часті зміни вимог подібні до смерті. На відміну від них, рухомі процеси адаптують зміни

29

Лекція 3. Організація технологічного процесу розробки ПЗ

вимог і навіть виграють від цього. Словом, рухомі процеси мають адаптивну природу.

Таким чином, в сучасній інфраструктурі програмної інженерії існують два сімейства процесів розробки:

сімейство строго прогнозованих (важких) процесів розроблення ПП; сімейство адаптивних (рухомих, полегшених) процесів розроблення ПП. У кожного сімейства є свої Переваги, недоліки і область застосування:

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

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

4. ХР-процесс

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

Основна ідея ХР — усунути високу вартість зміни, характерну для застосувань з використанням об'єктів, паттернів і реляційних баз даних. Тому ХР-процесс повинен бути високодинамічним процесом. ХР-группа має справу із змінами вимог на всьому протязі ітераційного циклу розробки, причому цикл складається з дуже коротких ітерацій. Чотирма базовими діями в ХРцикле є: кодування, тестування, вислухування замовника і проектування. Динамізм забезпечується за допомогою чотирьох характеристик: безперервного зв'язку із замовником (і в межах групи), простоти (завжди вибирається мінімальне рішення), швидкого зворотного зв'язку (за допомогою модульного і функціонального тестування), сміливості в проведенні профілактики можливих проблем.

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

Таблиця 1.2. Екстремуми в екстремальному програмуванні

Базис ХР утворюють перераховані нижче12 методів.

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

2.Часта зміна версій (Small releases) — швидкий запуск у виробництво простій системи. Нові

30

Лекція 3. Організація технологічного процесу розробки ПЗ версії реалізуються в дуже короткому (двотижневому) циклі.

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) — повинні витримуватися правила, що забезпечують однакове представлення програмної коди у всіх частинах програмної системи.

Розглянемо структуру «ідеального» ХР-процесса. Основним структурним елементом процесу є ХР-реализация, в яку багато разів вкладається базовий елемент — ХР-итерация. До складу ХРреализации і ХР-итерации входять три фази — дослідження, блокування, регулювання. Дослідження (exploration) — це пошук нових вимог (історій, завдань), які повинна виконувати система. Блокування (commitment) — вибір для реалізації конкретної підмножини зі всіх можливих вимог (іншими словами, планування). Регулювання (steering) — проведення розробки, втілення плану в життя.

Мал. 1.8. Ідеальний ХР-процесс

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

31

Лекція 3. Організація технологічного процесу розробки ПЗ

розробників не перевищує 10 чоловік. ХР-процесс для проекту з сім'ю реалізаціями, здійснюваний за 15 місяців, показаний на мал. 1.8.

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

Передбачається, що тривалість першої реалізації складає 3 місяці, тривалість другої — сьомий реалізацій — 2 місяці. Друга — сьома реалізації утворюють період супроводу, що характеризує природу ХР-проекта. Кожна ітерація триває два тижні, за винятком тих, які відносять до пізньої стадії реалізації, — «запуску у виробництво» (в цей час темп ітерації прискорюється).

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

32