WikiSort.ru - Программирование

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

История

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

Первое описание FDD появилось в 1999 году в главе 6 книги Java Modeling in Color with UML. В книге A Practical Guide to Feature-Driven Development (2002 год) описание FDD было обобщено, и в частности избавлено от привязок к конкретному языку программирования.

Обзор

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

1. разработка общей модели;
2. составление списка необходимых функций системы;
3. планирование работы над каждой функцией;
4. проектирование функции;
5. реализация функции.

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

Этапы

Так как функции малы, то их разработка — относительно легкая задача. Для мониторинга проекта по разработке ПО и предоставления точных данных о развитии проекта необходимо протоколировать разработку каждого свойства (функции). 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