Feature driven development

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Разработка программного обеспечения
Процесс разработки ПО
Шаги процесса

Анализ • Проектирование • Программирование • Документирование • Тестирование

Модели

Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model

Методологии

Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD

Сопутствующие дисциплины

Конфигурационное управление • Управление проектами • Управление требованиями

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

История[править | править вики-текст]

FDD была изначально предложена Джеффом Де Люкой (англ. Jeff De Luca) для проекта (рассчитанного на 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 включает в себя пять базовых видов деятельности:

Fdd process diagram.png
  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)

Ссылки[править | править вики-текст]