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

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

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

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

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

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

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

Разработайте общую модель [ править ]

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

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

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

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

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

Дизайн по функциям [ править ]

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

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

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

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

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

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

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

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

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

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

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

Используемые инструменты [ править ]

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

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

• Гибкая разработка программного обеспечения
• Поведенческая разработка
• Жизненный цикл проекта
• Архитектура программного обеспечения
• Процесс разработки программного обеспечения
• Программная инженерия

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

• 1. ^ Коад, П. , Лефевр, Э. и Де Лука, Дж. (1999). Java-моделирование в цвете с помощью UML: корпоративные компоненты и процессы . Prentice Hall International. ( ISBN 0-13-011510-X ) 
• 2. ^ Palmer, SR, и Felsing, JM (2002). Практическое руководство по разработке, основанной на функциях . Прентис Холл. ( ISBN 0-13-067615-2 ) 

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

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