10. Моделі розробки програмного забезпечення. Методологія fdd, Extreme Programming (xp).

7. FDD (Feature Driven Development) – функціонально-орієнтована розробка. Використовуване в FDD поняття функції чи властивості (feature) системи достатньо близько до поняття прецеденту використання, що використовується в RUP, істотна відмінність – це додаткове обмеження: «кожна функція має допускати реалізацію не більш, ніж за два тижні». Тобто якщо сценарій використання достатньо малий, його можна вважати функцією. Якщо ж великий, то його треба розбити на кілька відносно незалежних функцій.

FDD передбачає п‘ять процесів, останні два з яких повторюються для кожної функції:

• Розробка загальної моделі;

• Складання списку необхідних функцій системи;

• Планування роботи над кожною функцією;

• Проектування функцій;

• Конструювання функцій.

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

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

5. Модель екстремального програмування (XP). Extreme Programming – екстремальне програмування – є найбільш відомим з гнучких методологій. Вона будується на 12 принципах, які можна об‘єднати у 4 групи [1]:

1) Короткий цикл зворотного зв‘язку:

• Розробка через тестування

• Гра в планування

• Замовник завжди поряд

• Парне програмування

2) Неперервний, а не пакетний процес:

• Неперервна інтеграція

• Рефакторінг

• Часті невеликі релізи

3) Розуміння, що поділяється всіма

• Простота

• Метафора системи

• Колективне володіння кодом чи вибраними шаблонами проектування

• Стандарт кодування

4) Соціальна захищеність програміста

• 40-годинний робочий тиждень

XP, без сумніву, дуже популярне і дозволяє розробляти проекти достатньо успішно, але тільки в ідеальному варіанті. В реальності все набагато складніше [1]:

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

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

• Колективне володіння кодом — ще один спірний момент. За кожен клас має відповідати тільки один розробник: при колективному володінні можливі неочікувані правки, і клас стане працювати не так, як було заплановано розробником класу.

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