Feature Driven Development

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку

Feature driven development (FDD, розробка, керована функціональністю) — ітеративна методологія розробки програмного забезпечення, одна з гнучких методологій розробки (agile). FDD являє собою спробу об'єднати найбільш визнані в індустрії розробки програмного забезпечення методики, які беруть за основу важливу для замовника функціональність (властивості) розроблюваного програмного забезпечення. Основною метою даної методології є розробка реального, працюючого програмного забезпечення систематично, в поставлені терміни.

Історія

[ред. | ред. код]

FDD була запропонована Джеффом Де Люка для проєкту (розрахованого на 15 місяців і 50 осіб) з розробки програмного забезпечення для одного великого Сінгапурського банку в 1997 році. Де Люка виділив набір з п'яти процесів, що охоплює як розробку загальної моделі, так і ведення списку, планування, проєктування і реалізацію елементів функціональності (англ. feature).

Перший опис FDD з'явився в 1996 році в главі 6 книги Java Modeling in Color with UML [1]. У книзі A Practical Guide to Feature-Driven Development [2] (2002 рік) опис FDD було узагальнено, і зокрема позбавлено від прив'язок до конкретної мови програмування.

Огляд

[ред. | ред. код]

FDD включає в себе п'ять базових видів діяльності:

  1. Розробка загальної моделі;
  2. Складання списку необхідних функцій системи;
  3. Планування роботи над кожною функцією;
  4. Проєктування функції;
  5. Реалізація функції.

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

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

[ред. | ред. код]

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

Складання списку можливостей (функцій)

[ред. | ред. код]

Інформація, зібрана при побудові загальної моделі, використовується для складання списку функцій. Це здійснюється розбиттям областей (англ. domain) на підобласті (предметні області, англ. subject areas) з точки зору функціональності. Кожна окрема підобласть відповідає якомусь бізнес-процесу, кроки якого стають списком функцій (властивостей). У даному випадку функції - це маленькі частини розуміються користувачем функцій, представлених у вигляді «<дія> <результат> <об'єкт>», наприклад, «перевірка пароля користувача». Розробка кожної функції повинна займати не більше 2 тижнів, інакше задачу необхідно розбити на кілька підзадач, кожна з яких зможе бути завершена за встановлений двотижневий термін.

План за властивостями (функціями)

[ред. | ред. код]

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

Проєктування функцій

[ред. | ред. код]

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

Реалізація функції

[ред. | ред. код]

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

Етапи

[ред. | ред. код]

Так як функції малі, то їх розробка - відносно легке завдання. Для моніторингу проєкту з розробки ПЗ і надання точних даних про розвиток проєкту необхідно протоколювати розробку кожної властивості (функції). FDD виділяє шість послідовних етапів для кожної функції (властивості). Перші три повністю завершуються в процесі проєктування, останні три - в процесі реалізації. Для зручності контролю за виконанням робіт на кожному етапі показується відсоток його готовності (виконання). У таблиці нижче наведені основні етапи. Функція, яка все ще знаходиться в розробці, завершена на 44% (Аналіз області 1% + Дизайн 40% + Перевірка дизайну 3% = 44%)

Таблиця 1. Основні етапи
Аналіз області Дизайн Перевірка дизайну Код Перевірка коду Включення до збірки
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)

Посилання

[ред. | ред. код]