Feature driven development

Материал из Википедии — свободной энциклопедии
Это старая версия этой страницы, сохранённая РоманСузи (обсуждение | вклад) в 06:11, 15 июля 2012 (→Передовой опыт: оформление). Она может серьёзно отличаться от текущей версии.
Перейти к навигации Перейти к поиску
Разработка программного обеспечения
Ключевые процессы
Парадигмы и модели
Методологии
Инструменты

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

История

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

Первое описание FDD появилось в 1996 году в главе 6 книги Java Modeling in Color with UML[1]. В книге A Practical Guide to Feature-Driven Development[2] (2002 год) описание FDD было обобщено, и в частности отделено от «java modeling in color».

Обзор

Feature-driven development — разработка, управляемая функциональностью. FDD включает в себя пять базовых видов деятельности:

  • Разработка общей модели
  • Составление списка необходимых функций системы
  • Планирование работы над каждой функцией
  • Проектирование функции
  • Реализация функции

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

Разработка общей модели

Разработка начинается с высокоуровневого сквозного анализа широты решаемого круга задач и контекста системы. Далее для каждой моделируемой области делается более детальный сквозной анализ. Сквозные описания составляются в небольших группах и выносятся на дальнейшее обсуждение и экспертную оценку. Одна из предлагаемых моделей или их объединение становится моделью для конкретной области. Модели каждой области задач объединяются в общую итоговую модель, которая изменяется в ходе работы.

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

Информация, собранная при построении общей модели, используется для составления списка функций. Это осуществляется разбиением областей (domain) на подобласти (subject areas) с точки зрения функциональности. Каждая отдельная подобласть соответствует какому-либо бизнес-процессу, шаги которого становятся списком функций (свойств). В данном случае функции — это маленькие части понимаемых пользователем функций, представленных в виде "<действие> <результат> <объект>", например, «проверка пароля пользователя». Разработка каждой функции должна занимать не более 2 недель, иначе задачу необходимо разбить на несколько подзадач, каждая их которых сможет быть завершена за установленный двухнедельный срок.

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

После составления списка основных функций, наступает черед составления плана разработки ПО. Владение классами распределяется среди ведущих программистов путем упорядочивания и организации свойств (или наборов свойств) в классы.

Проектирование функций

Для каждого свойства создается проектировочный пакет. Ведущий программист выделяет небольшую группу свойств для разработки в течение двух недель. Вместе с разработчиками соответствующего класса ведущий программист составляет подробные диаграммы последовательности для каждого свойства, уточняя общую модель. Далее пишутся "болванки" классов и методов, и происходит критическое рассмотрение дизайна.

Реализация функции

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

Этапы

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

Таблица 1. Основные этапы
Анализ области Дизайн Проверка дизайна Код Проверка кода Включение в сборку
1 % 40 % 3 % 45 % 10 % 1 %

Передовой опыт

FDD построен на основе набора передового опыта (набора наилучших практик), признанного в отрасли и полученного из инженерии программного обеспечения. Эти практические методы строятся с точки зрения важного для клиента функционала. Ниже дано краткое описание каждого метода:

  • Объектное моделирование области. Объектное моделирование состоит из исследования и выяснения рамок предметной области решаемой задачи. Результатом является общий каркас, который можно в дальнейшем дополнять функциями.
  • Разработка по функции. Любая функция, которая слишком сложна для разработки в течение двух недель, разбивается на меньшие подфункции до тех пор, пока каждая подзадача не может быть названа свойством (то есть, быть реализована за 2 недели). Это облегчает создание корректно работающих функций, расширение и модификацию системы.
  • Индивидуальное владение классом (кодом). Означает, что каждый блок кода закреплён за конкретным владельцем-разработчиком. Владелец ответственен за согласованность, производительность и концептуальную целостность своих классов.
  • Команда по разработке функций (свойств). Команда по разработке функций (свойств) — маленькая, динамически формируемая команда разработчиков, занимающаяся небольшой подзадачей. Позволяет нескольким умам участвовать в дизайне свойства, а также оценивать дизайнерские решения перед выбором наилучшего.
  • Проверки. Проверки обеспечивают хорошее качество кода, в первую очередь путём выявления ошибок.
  • Конфигурационное управление. Помогает с идентификацией исходного кода для всех функций (свойств), разработка которых завершена на текущий момент, и с протоколированием изменений, сделанных разработчиками классов.
  • Регулярная сборка. Регулярная сборка гарантирует, что всегда есть продукт (система), которая может быть представлена клиенту, и помогает находить ошибки при объединении частей исходного кода на ранних этапах.
  • Обозримость хода работ и результатов. Частые и точные отчеты о ходе выполнения работ на всех уровнях внутри и за пределами проекта о выполненной работе помогают менеджерам правильно руководить проектом.

Метамодель

Метамодель (см. диаграмму) иллюстрирует процессы и данные метода, делая возможным сравнение методов и повторное использование их фрагментов. Преимущество данный техники в том, что она компактна, ясна и соответствует стандартам UML. Левая часть метаданных модели показывает 5 основных видов деятельности, входящих в проект разработки ПО, использующий FDD. Все процессы имеют подпроцессы, соответствующие подпроцессам в описании FDD-процессов, описанных на сайте Джеффа Де Люка. Правая часть модели показывает задействованные концепции, относящиеся к видам деятельности, данным слева.

Критика

В применении FDD к веб-разработкам были выявлены следующие положительные стороны[1]:

  1. Прекрасное планирование и отчётность
  2. Высокая дисциплина и ясность
  3. Фокус на клиенте
  4. Уменьшение рисков через:
    1. итеративность проектирования и реализацию небольшими частями
    2. ясность требований
    3. бо́льшее понимание разрабатываемой системы
    4. уменьшение места для манёвра, так как требуется меньше предположений

Отрицательные стороны (там же):

  1. Высокая зависимость от технических лидеров
  2. Не касается проектирования и построения графического интерфейса
  3. Менее эффективно для небольших проектов по сравнению с большими
  4. Не касается тестирования и внедрения

К сожалению, такие области, как обеспечение качества, оценка рисков и т.п. данная модель обходит стороной. FDD подходит для небольших проектов, срок реализации которых составляет несколько месяцев. Для долгосрочных проектов, со сроком производства год или более, предпочтительно выбрать другую, более формализованную модель.[источник не указан 4669 дней]

CASE-средства для FDD

См. также

Гибкая методология разработки

Ссылки

Примечания

  • 1. ↑ 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)
  • 2. ↑ Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall. (ISBN 0-13-067615-2)
  1. ↑ Successful Development
Источник — https://ru.wikipedia.org/w/index.php?title=Feature_driven_development&oldid=46131384