Feature driven development

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

FDD была изначально предложена Джеффом Де Люкой (англ. Jeff De Luca) для проекта (рассчитанного на 15 месяцев и 50 человек) по разработке программного обеспечения для одного крупного сингапурского банка в 1997 году. Де Люка выделил набор из пяти процессов, охватывающий как разработку общей модели, так и ведение списка, планирование, проектирование и реализацию элементов функциональности (англ. feature).

Первое описание FDD появилось в 1999 году в главе 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 %)

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)

• Feature Driven Development Community
• FDD and Agile Modeling
• Interview with FDD-Creator Jeff DeLuca