Requirement management (rus)

Feature Driven Development

Введение

Эта методология (кратко именуемая FDD) была разработана Джеффом Де Люка (Jeff De Luca) и признанным гуру в области объектно-ориентированных технологий Питером Коадом (Peter Coad). Как и остальные адаптивные методологии, она делает основной упор на коротких итерациях, каждая из которых служит для проработки определенной части функциональности системы. Согласно FDD, одна итерация длится две недели. FDD насчитывает пять процессов. Первые три из них относятся к началу проекта.

  1. Разработка общей модели
  2. Составление списка требуемых свойств системы
  3. Планирование работы над каждым свойством
  4. Проектирование каждого свойства
  5. Конструирование каждого свойства

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

Наиболее полное описание методологии FDD можно найти в книге Питера Коада со товарищи, под названием “UML in Color” . Его компания, “TogetherSoft”, также занимается консалтингом и обучением FDD.

Текст выше взят отсюда. Перевел последовательность действий:

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

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

Составление списка требуемых свойств системы

Знания при создании модели используются для построения списка фич (свойств системы). Это сделано при помощи функциональной декомпозиции домена по предметным областям. Они содержать бизнес-активности, а так же описание, какая из бизнес-активностей формирует какой список фич. Фичи являются малыми составляющими клиентский функций, например: “посчитать количество продаж”. Фичи должны быть реализованы не более чем за 2 недели, иначе их следует делить на меньшие части.

Планирование работы над каждым свойством

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

Проектирование каждого свойства

Под дизайном здесь не понимается дизайн интерфейса. Уточняется диаграмма последовательности по группе фич, которые можно реализовать за 2 недели.

Конструирование каждого свойства

Разработка.

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

Тут мне была интересна только декомпозиция.

Вопросы и примечания

Не очень мне тут понятно, когда у нас идет дизайн интерфейса и описываются конкретные поля… Мы же, по идее, должны протрассировать фичи на элементы интрефейса..

Правильно ли я перевел рисунок отсюда..?

 

Комментарий пользователя Shur с uml2.ru:

В тексте приводится определение “Фича – небольшая часть функции в форме <действие> <результат> <объект>, с результатом, имеющим ценность с точки зрения клиента. Например – “рассчитать суммарный объем продаж” или “проверить пароль пользователя”.

В смысле этого определения фича может иметь вид “заполнить <название поля> интерфейсной формы значением <название показателя>”.

Из текста раздела Buid feature list следует, что система декомпозируется по иерархии:
автоматизируемая область (домен) -> предметные области (subject areas) -> виды деятельности (business activities) -> список фич.
Причем каждой фиче соответствует действие (по крайней мере) одного из видов деятельности (activity).

Advertisements
Standard

4 thoughts on “Feature Driven Development

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s