Разработка, ориентированная на функции

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

История [ править ]

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

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

Обзор [ править ]

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

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

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

Список функций сборки [ править ]

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

Планирование по функциям [ править ]

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

Дизайн по характеристикам [ править ]

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

Сборка по функциям [ править ]

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

Вехи [ править ]

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

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

Лучшие практики [ править ]

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

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

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

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

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

См. также [ править ]

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

^ «Принципы Agile-манифеста» . 11.06.2019.

1. ^ Коад, П. , Лефевр, Э. и Де Лука, Дж. (1999). Цветное моделирование Java с помощью UML: компоненты и процессы предприятия . Прентис Холл Интернэшнл. ( ISBN 0-13-011510-X )
2. ^ Палмер, С.Р., и Фельсинг, Дж.М. (2002). Практическое руководство по функционально-ориентированной разработке . Прентис Холл. ( ISBN 0-13-067615-2 )

Внешние ссылки [ править ]

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

[1] «Принципы Agile-манифеста» . 11.06.2019.

[1]