Декомопозиция задач - Управление требованиями

# > Общий раздел (Russian) > Руководства > Руководство пользователя > Декомпозиция задач > Декомопозиция задач - Управление требованиями

Описание

Декомопозиция задач - Управление требованиями

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

Данный подход может быть использован в следующих случаях:

Следуя простым правилам декомпозиции задач, изложенным ниже, команда автоматически, не прикладывая особых усилий, получает ответы на такие распространенные в процессе разработки вопросы:

Дополнительно следует отметить такие благоприятные эффекты:

Управление требованиями

Рассмотрим типовой для разработки ПО сценарий: в backlog проекта, разрабатываемого по методологии Scrum, появляется user story "Уведомления о новых темах/задачах" с формулировкой:

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

Данная задача является первичным требованием (или исходной задачей), зачастую по сути просто идеей, выраженной на языке заказчика, перед дальнейшей разработкой обычно требуется провести дополнительный анализ, в процессе которого требование уточняется и расширяется. Для декомпозиции этого требования мы будем следовать методологии, которая используется при разработке самого Project Kaiser, вкратце ее суть такова. В проекте создается два элемента типа "Требования" - funcs и comps, в первую помещаются функциональные требования, во вторую - требования к компонентам системы, при помощи которых реализуются функциональные требования.

Рассмотрим рекомендованную структуру развитого проекта:

Управление задачами: структура проекта

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

Компоненты(модули) соответствуют крупным пакетам исходного кода:

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

2933790^decomp-prj-expanded-ru.png

Рассмотрим решение по шагам. В разделе, соответствующем Руководству пользователя, создается требование "Подписка на новые документы(файлы)" (в процессе анализа было решено немного изменить формулировку) и связывается с исходным требованием: исходное требование указывается как сверхзадача, таким образом "Подписка..." становится внешней подзадачей для исходной задачи "Уведомления...". Внутри usr cразу был создан модуль n10n (сокращение от n-otificatio-n) исходя из следующих соображений:

Одной исходной задаче в backlog обычно соответствует одно новое требование в соответствующем Руководстве, но встречаются задачи, которые требуют декомпозиции на несколько требований в разных руководствах. Достаточно распространенным случаем является добавление требований, соответствующих Руководству пользователя и Руководству администратора одновременно - так происходит, если функция будет требовать настройки со стороны администратора системы.

Анализ выявил следующие особенности задачи:

Все эти нюансы отражаются в тексте функционального требования "Подписка..." (напомним, этот документ находится в разделе, соответствующем Руководству пользователя). Теперь приступим к проектированию компонентов.

В GUI мы добавим настройку "Уведомлять/не уведомлять о новых" - создаем соответствующий элемент в модуле gui. Возникает вопрос - куда сохранять настройки? Можно завести новую таблицу или модифицировать уже существующую. Этот путь признается тупиковым, вместо этого принимается решение модуль fs расширить понятием "свойство", чтобы можно было сохранять пары имя-значение, не создавая каждый раз новые поля в таблицах. Таким образом в модуле fs появляется элемент IUserProperty, у которого сверхзадачей указано требование "Настройка...". Для реализации IUserProperty требуется таблица user_property - создаем соответствующее требование в модуле db, указав IUserProperty как сверхзадачу. Можно продолжить декомпозицию и дальше, создавая требования к классам, которые реализуют этот интерфейс, и связывая их с предыдущими требованиями, но и в этом примере и в его реальном прототипе мы на этом остановимся - решение достаточно задокументировано и понятно разработчику.

Кто будет рассылать уведомления? У нас имеется подходящий кандидат - сервис Notifier в модуле services, он уже рассылает уведомления по другим поводам, его можно легко доработать, поэтому мы не будем создавать нового требования, а создадим внутри Notifier подзадачу на изменение и укажем для нее функциональное требование "Подписка..." в качестве сверхзадачи.

Посмотрим, как выглядит теперь исходная задача в backlog:

Управление задачами: декомпозиция запроса

Колонка "Путь" меняет свое значение каждый раз, когда создается внешняя подзадача, и указывает на место в дереве проекта, где эта подзадача была создана. Таким образом, в списке backlog все вложенные в "Уведомления о новых темах/форумах" задачи являются по отношению к ней внешними подзадачами, на что указывают значения колонки "Путь".

В качестве основы для разобранного примера была взята реальная задача из backlog системы Project Kaiser, см. Подписка на новые документы(файлы).

Создание внешних подзадач

См. Создание внешних подзадач.

Глубина декомпозиции

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

Распределение задач между отделами

Допустим, у нас имеется следующая структура некоего предприятия:

Заказ поступает в отдел заказов, там создается задача. Для ее решения создаются внешние подзадачи в отделах проектирования/производства/доставки для которых исходная задача указывается как сверхзадача.

В качестве примера сочетания распределения задач и управления требованиями рассмотрим реальную задачу из Project Kaiser Customer Zone - проекта, в котором осуществляется поддержка коммерческих пользователей Project Kaiser.

Управление задачами: customer zone

В папке Предложения проекта Customer Zone.ru пользователь создал задачу "Оповещения...", суть которой сводилась к тому, чтобы пользователи получали сообщения на почту о новых темах в форуме независимо от прочтения предыдущих. Для ее решения в backlog уже другого проекта - PK - была создана внешняя подзадача, которая была декомпозирована в функциональные требования к системе и ее компонентам. По схеме решения видно, что серверная часть вынесена в отдельный проект Srv и там есть функция Subscription, которая была изменена подзадачей, связанной с новым функциональным требованием. Новое функциональное требование "Option: Always..." был создано в разделе, соотвествующем Руководству пользователя и отражено в документации Настройка: всегда уведомлять о новых.

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

Комментарии

18.03.11 6:45 maxim.ge

Демо-проект: Project

Project Kaiser Team
Все права защищены. ©Triniforce 2006-2019
Создан: maxim.ge 16.03.11 11:02; Изменен: michael.say 02.06.11 13:46
Эта страница является подготовленной к печати версией файла "Декомопозиция задач - Управление требованиями".
Подготовлено с помощью Project Kaiser - программы для управления проектами и задачами
Пользователь:Guest