Feature Driven Development
Feature driven development (FDD, розробка, керована функціональністю) — ітеративна методологія розробки програмного забезпечення, одна з гнучких методологій розробки (agile). FDD являє собою спробу об'єднати найбільш визнані в індустрії розробки програмного забезпечення методики, які беруть за основу важливу для замовника функціональність (властивості) розроблюваного програмного забезпечення. Основною метою даної методології є розробка реального, працюючого програмного забезпечення систематично, в поставлені терміни.
| Цикл розробки програмного забезпечення |
|---|
 Програміст за роботою |
| Діяльність і кроки |
| Допоміжні дисципліни |
| Практики |
| Інструменти |
|
| Стандарти та галузі знань |
Історія
FDD була запропонована Джеффом Де Люка для проекту (розрахованого на 15 місяців і 50 осіб) з розробки програмного забезпечення для одного великого Сінгапурського банку в 1997 році. Де Люка виділив набір з п'яти процесів, що охоплює як розробку загальної моделі, так і ведення списку, планування, проектування і реалізацію елементів функціональності (англ. feature).
Перший опис FDD з'явився в 1996 році в главі 6 книги Java Modeling in Color with UML . У книзі A Practical Guide to Feature-Driven Development (2002 рік) опис FDD було узагальнено, і зокрема позбавлено від прив'язок до конкретної мови програмування.
Огляд
FDD включає в себе п'ять базових видів діяльності:
- Розробка загальної моделі;
- Складання списку необхідних функцій системи;
- Планування роботи над кожною функцією;
- Проектування функції;
- Реалізація функції.
Перші два процеси відносяться до початку проекту. Останні три здійснюються для кожної функції. Розробники в FDD діляться на «господарів класів» і «головних програмістів». Головні програмісти залучають господарів задіяних класів до роботи над черговою властивістю. Робота над проектом передбачає часті збірки і ділиться на ітерації, кожна з яких передбачає реалізацію певного набору функцій.
Розробка загальної моделі
Розробка починається з високорівневого наскрізного аналізу обсягу кола вирішуваних завдань і контексту системи. Далі для кожної модельованої області робиться більш детальний наскрізний аналіз. Наскрізні опису складаються в невеликих групах і виносяться на подальше обговорення та експертну оцінку. Одна з пропонованих моделей або їх об'єднання стає моделлю для конкретної області. Моделі кожній області завдань об'єднуються в загальну підсумкову модель, яка змінюється в ході роботи.
Складання списку можливостей (функцій)
Інформація, зібрана при побудові загальної моделі, використовується для складання списку функцій. Це здійснюється розбиттям областей (англ. domain) на підобласті (предметні області, англ. subject areas) з точки зору функціональності. Кожна окрема підобласть відповідає якомусь бізнес-процесу, кроки якого стають списком функцій (властивостей). У даному випадку функції - це маленькі частини розуміються користувачем функцій, представлених у вигляді «<дія> <результат> <об'єкт>», наприклад, «перевірка пароля користувача». Розробка кожної функції повинна займати не більше 2 тижнів, інакше задачу необхідно розбити на кілька підзадач, кожна з яких зможе бути завершена за встановлений двотижневий термін.
План за властивостями (функціями)
Після складання списку основних функцій, настає черга складання плану розробки програмного забезпечення. Володіння класами розподіляється серед провідних програмістів шляхом упорядкування та організації властивостей (або наборів властивостей) в класи.
Проектування функцій
Для кожної властивості створюється проектувальний пакет. Провідний программіст виділяє невелику групу властивостей для розробки протягом двох тижнів. Разом з розробниками відповідного класу провідний програміст складає докладні діаграми послідовності для кожної властивості, уточнюючи загальну модель. Далі пишуться «болванки» класів і методів, і відбувається критичний розгляд дизайну.
Реалізація функції
Після успішного розгляду дизайну, дана видима клієнту функціональність реалізується до стану готовності. Для кожного класу пишеться програмний код. Після модульного тестування кожного блоку і перевірки коду, завершена функція включається в основний проект (англ. build).
Етапи
Так як функції малі, то їх розробка - відносно легке завдання. Для моніторингу проекту з розробки ПЗ і надання точних даних про розвиток проекту необхідно протоколювати розробку кожної властивості (функції). FDD виділяє шість послідовних етапів для кожної функції (властивості). Перші три повністю завершуються в процесі проектування, останні три - в процесі реалізації. Для зручності контролю за виконанням робіт на кожному етапі показується відсоток його готовності (виконання). У таблиці нижче наведені основні етапи. Функція, яка все ще знаходиться в розробці, завершена на 44% (Аналіз області 1% + Дизайн 40% + Перевірка дизайну 3% = 44%)
| Аналіз області | Дизайн | Перевірка дизайну | Код | Перевірка коду | Включення до збірки |
| 1 % | 40 % | 3 % | 45 % | 10 % | 1 % |
Передовий досвід
FDD побудований на основі набору передового досвіду (набору найкращих практик), визнаного в галузі і отриманого з інженерії програмного забезпечення. Ці практичні методи будуються з точки зору важливого для клієнта функціоналу. Нижче подано короткий опис кожного методу:
- Об'єктне моделювання області. Об'єктне моделювання складається з дослідження і з'ясування рамок предметної області розв'язуваної задачі. Результатом є загальний каркас, який можна надалі доповнювати функціями.
- Розробка по функції. Будь-яка функція, яка занадто складна для розробки протягом двох тижнів, розбивається на менші підфункції до тих пір, поки кожна підзадача не може бути названа властивістю (тобто, бути реалізована за 2 тижні). Це полегшує створення коректно працюючих функцій, розширення і модифікацію системи.
- Індивідуальне володіння класом (кодом). Означає, що кожен блок коду закріплений за конкретним власником-розробником. Власник відповідальний за узгодженість, продуктивність і концептуальну цілісність своїх класів.
- Команда з розробки функцій (властивостей). Команда з розробки функцій (властивостей) - маленька команда розробників, яка формується динамічно і займається невеликою підзадачею. Дозволяє декільком розробникам брати участь у дизайні властивості, а також оцінювати дизайнерські рішення перед вибором найкращого.
- Перевірка коду (англ. code review) Перевірки забезпечують хорошу якість коду, в першу чергу шляхом виявлення помилок.
- Конфігураційне управління. Допомагає з ідентифікацією вихідного коду для всіх функцій (властивостей), розробка яких завершена на поточний момент, і з протоколюванням змін, зроблених розробниками класів.
- Регулярна збірка. Регулярна збірка гарантує, що завжди є продукт (система), яка може бути представлена замовнику, і допомагає знаходити помилки при об'єднанні частин вихідного коду на ранніх етапах.
- Осяжність ходу робіт і результатів. Часті і точні звіти про хід виконання робіт на всіх рівнях всередині і за межами проекту допомагають менеджерам правильно керувати проектом.
Див. Також
Примітки
Література
- ↑ Coad, P., Lefebvre, E. & De Luca, J. (1999). Java Modeling In Color With UML: Enterprise Components and Process. Prentice Hall International. (ISBN 0-13-011510-X)
- ↑ Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall. (ISBN 0-13-067615-2)
- Alan S. Koch. Agile Software Development: Evaluating the Methods for Your Organization. — Artech House, 2004. — 280 с. — ISBN 978-1580538428. (Appendix F)