Введение

Процесс разработки программного обеспечения

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

История

FDD был первоначально разработан Джеффом Де Лукой для удовлетворения специфических потребностей 15-месячного проекта по разработке программного обеспечения, в котором участвовали 50 человек, для крупного сингапурского банка в 1997 году. Это привело к созданию набора из пяти процессов, охватывающих разработку общей модели, а также определение, планирование, проектирование и реализацию функций. Первый процесс во многом основан на подходе Питера Коада к объектному моделированию. Второй процесс включает идеи Коада об использовании списка функций для управления функциональными требованиями и задачами разработки. Остальные процессы являются результатом опыта Джеффа Де Луки. После успешного применения FDD в сингапурском проекте было осуществлено несколько его внедрений. Описание FDD впервые было представлено миру в 6-й главе книги "Java modelling in Color with UML" авторства Питера Коада, Эрика Лефевра и Джеффа Де Луки в 1999 году. Впоследствии, в книге Стивена Палмера и Мака Фелсинга "Практическое руководство по Feature Driven Development" (опубликовано в 2002 году) было представлено более общее описание FDD, не связанное с моделированием на Java.

Обзор

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

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

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

Создать список функций

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

План по особенностям

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

Дизайн по особенностям

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

Создать по функциям

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

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

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

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

Метамоделирование позволяет визуализировать как процессы, так и данные метода. Это обеспечивает возможность сравнения методов, а фрагменты методов в процессе проектирования методов могут быть легко повторно использованы. Использование данной техники соответствует стандартам UML. Левая часть модели метаданных отображает пять основных видов деятельности, вовлеченных в проект разработки программного обеспечения с использованием FDD. Каждый из этих видов деятельности содержит поддеятельности, соответствующие поддеятельностям в описании процесса FDD. Правая часть модели демонстрирует задействованные понятия, которые происходят из видов деятельности, изображенных на левой стороне диаграммы.