Разработка на основе функций - Feature-driven development

Разработка на основе функций (FDD) является итеративный и инкрементный процесс разработки программного обеспечения. Это легкий или же Гибкий метод для развития программного обеспечения. FDD сочетает в себе ряд признанных в отрасли лучшие практики в единое целое. Эти практики основаны на полезной для клиента функциональности (особенность ) перспектива. Его основная цель - постоянно и своевременно предоставлять реальное, работающее программное обеспечение в соответствии с Принципами, лежащими в основе Agile Manifesto.^[1]

История

FDD был первоначально разработан Джефф Де Лука для удовлетворения конкретных потребностей 15-месячного проекта разработки программного обеспечения с участием 50 человек в целом Сингапур bank в 1997 году. Результатом этого стал набор из пяти процессов, охватывающих разработку общей модели и составление списков, планирование, проектирование и создание функций. Первый процесс сильно зависит от Питер Коуд подход к объектное моделирование. Второй процесс включает в себя идеи Coad об использовании списка функций для управления функциональными требованиями и задачами разработки. Остальные процессы - результат опыта Джеффа Де Луки. С момента успешного использования в сингапурском проекте было несколько применений FDD.

Описание FDD было впервые представлено миру в главе 6 книги. Моделирование Java в цвете с помощью UML^[1] Питер Коуд, Эрик Лефевр и Джефф Де Лука в 1999 году. Позже Стивен Палмер и Mac Felsing книга Практическое руководство по разработке на основе функций^[2] (опубликовано в 2002 г.) было дано более общее описание FDD без привязки к моделированию Java.

Обзор

FDD - это управляемый моделями процесс коротких итераций, который состоит из пяти основных действий. Для точной государственной отчетности и отслеживания проекта разработки программного обеспечения, вехи которые отмечают прогресс, достигнутый по каждой функции. В этом разделе дается общий обзор деятельности. На рисунке справа модель метапроцесса для этих действий отображается. Во время первых двух последовательных действий общая модель форма установлена. Последние три вида деятельности: повторяется для каждой функции.

Модель процесса для FDD

Разработайте общую модель

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

Список функций сборки

Знания, собранные во время начального моделирования, используются для определения списка функций путем функционального разделения предметной области на предметные области. Каждая предметная область содержит бизнес-действия, а шаги в рамках каждого бизнес-действия формируют основу для категоризированного списка функций. Возможности в этом отношении представляют собой небольшие части оцениваемых клиентом функций, выраженных в форме «<действие> <результат> <объект>», например: «Подсчитать общую сумму продажи» или «Проверить пароль пользователя». На выполнение функций не должно уходить более двух недель, иначе их следует разбить на более мелкие части.

План по функции

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

Дизайн по функциям

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

Построить по функции

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

Вехи

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

Таблица 1: Основные этапы
Прохождение домена	Дизайн	Проверка дизайна	Код	Проверка кода	Продвигать к созданию
1%	40%	3%	45%	10%	1%

Лучшие практики

Разработка на основе функций основана на базовом наборе программная инженерия лучшие практики нацелен на перспективу полезной для клиента функции.

Моделирование предметных областей. Моделирование предметных областей состоит из исследования и объяснения предметной области решаемой проблемы. Результирующая объектная модель предметной области обеспечивает общую структуру для добавления функций.
Разработка по функциям. Любая функция, которая слишком сложна для реализации в течение двух недель, далее разбивается на более мелкие функции, пока каждая подзадача не станет достаточно маленькой, чтобы ее можно было назвать функцией. Это упрощает предоставление правильных функций и расширение или изменение системы.
Индивидуальный класс (код) Собственность. Индивидуальное владение классом означает, что отдельные части или группы кода назначаются одному владельцу. Владелец несет ответственность за согласованность, производительность и концептуальную целостность класса.
Функциональные команды. Специализированная команда - это небольшая, динамично сформированная команда, развивающая небольшую деятельность. К каждому проектному решению всегда применяются разные мнения, и несколько вариантов дизайна оцениваются перед тем, как выбрать один.
Инспекции. Инспекции выполняются для обеспечения хорошего качества дизайна и кода, прежде всего, путем обнаружения дефектов.
Управление конфигурацией. Управление конфигурацией помогает идентифицировать исходный код для всех функций, которые были завершены к настоящему моменту, и поддерживать историю изменений классов по мере их улучшения функциональными группами.
Регулярные сборки. Регулярные сборки гарантируют, что всегда есть актуальная система, которую можно продемонстрировать клиенту, и помогают выявить ошибки интеграции исходного кода для функций на раннем этапе.
Видимость прогресса и результатов. Менеджеры управляют проектом, используя частые, уместные и точные отчеты о ходе работ со всех уровней внутри и вне проекта на основе выполненных работ.

Метамодель (Метамоделирование)

Модель данных процесса для FDD

Метамоделирование помогает визуализировать как процессы, так и данные метод. Это позволяет сравнивать методы и фрагменты методов в методология процесс можно легко использовать повторно. Использование этого метода соответствует UML стандарты.

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

Используемые инструменты

CASE Spec. CASE Spec - это коммерческий корпоративный инструмент для функционально-ориентированной разработки.
TechExcel DevSuite. TechExcel DevSuite - это коммерческий набор приложений, обеспечивающий разработку на основе функций.
Инструменты FDD. Проект FDD Tools направлен на создание кроссплатформенного инструментария с открытым исходным кодом, поддерживающего методологию разработки, основанной на функциях.
FDD Viewer. FDD Viewer - это утилита для отображения и печати парковок.

Смотрите также

внешняя ссылка

Сообщество разработчиков, ориентированных на функции
Разработка на основе функций в Керли
Страница Nebulon FDD - Nebulon - это консалтинговая компания Джеффа Де Луки.
Успешные методологии веб-разработки - Использование FDD для проектов веб-разработки
Обеспечение реальной ценности для бизнеса с помощью разработки на основе функций - В статье дается базовый обзор FDD
FDD и Agile моделирование
Лучшее программное обеспечение быстрее - Еще одна книга из серии Coad, посвященная разработке, управляемой функциями. Авторы Энди Кармайкл и Дэн Хейвуд ISBN 0-13-008752-1
Интервью с создателем FDD Джеффом ДеЛукой (Подкаст)

[1] «Принципы Agile Manifesto». 2019-06-11.

[1]

[1]

[2]