Суть проблемы в том, что мне не совсем понятно как внести изменения в существующую структуру декомпозиции работ (составлена в MS Project 2010), и передать смысл этих изменений.
При добавление новых работ для реализации новой функциональности ПО в существующую СДР не отражается общее назначение этих работ.

Подробности:
Выполняется проект по разработке ПО.
Проект, вернее СДР, составлен по принципу "конечного продукта" и его составных частей, т. е. разрабатываемое ПО разделено на "подсистемы". Эти подсистемы в совокупности выполняют требуемые функции.
В общем СДР выглядит так:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3.
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.

Большая часть проекта уже выполнена, и сейчас решили добавить в разрабатываемое ПО еще одну функцию. Причем, хотим отследить ход разработки этой функциональности.
Например, чтобы эта функциональность была реализована, необходимо доработать подсистему 1 (создать новый элемент 1.4), подсистему 2 (доработать элемент 2.3), и подсистему 3 (создать элемент 3.4).
Список работ:
    - создать элемент 1.4
    - изменить элемент 2.3
    - создать элемент 3.4.
После добавления этих работ в СДР, сохраняя принцип построения СДР по конечному продукту, мы получим следующую СДР:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
    1.4. Элемент 1.4.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3. (изменение)
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.
    3.4. Элемент 3.4.

То есть мы потеряли целостный смысл этих трех добавленных работ: новая функциональность - она нигде не видна. Соответственно отследить ход выполнения этой функциональности также будет проблематично (хотя и возможно).

Можно доработать СДР так: создать новый пункт (4) и собрать работы для реализации новой функциональности в этот пункт:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3.
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.
4. Новая функциональность
    1.4. Элемент 1.4.
    2.3. Элемент 2.3. (изменение)
    3.4. Элемент 3.4.
Но так я считаю тоже будет неправильно. Так как теперь СДР составлена путем смешения разных подходов.

Как же правильно построить СДР, чтобы совместить и подход по результату и функциональный подход?
Для поиска ответа я даже для себя перевел документ PMI Practice Standard for WBS. 2nd edition. Однако четкого ответа так и не нашел. Там сказано, что можно строить и так, и так. Но как это совместить - не ясно.

Дайте пожалуйста какие-нибудь советы.

Суть проблемы в том, что мне не совсем понятно как внести изменения в существующую структуру декомпозиции работ (составлена в MS Project 2010), и передать смысл этих изменений.
При добавление новых работ для реализации новой функциональности ПО в существующую СДР не отражается общее назначение этих работ.

Подробности:
Выполняется проект по разработке ПО.
Проект, вернее СДР, составлен по принципу "конечного продукта" и его составных частей, т. е. разрабатываемое ПО разделено на "подсистемы". Эти подсистемы в совокупности выполняют требуемые функции.
В общем СДР выглядит так:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3.
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.

Большая часть проекта уже выполнена, и сейчас решили добавить в разрабатываемое ПО еще одну функцию. Причем, хотим отследить ход разработки этой функциональности.
Например, чтобы эта функциональность была реализована, необходимо доработать подсистему 1 (создать новый элемент 1.4), подсистему 2 (доработать элемент 2.3), и подсистему 3 (создать элемент 3.4).
Список работ:
    - создать элемент 1.4
    - изменить элемент 2.3
    - создать элемент 3.4.
После добавления этих работ в СДР, сохраняя принцип построения СДР по конечному продукту, мы получим следующую СДР:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
    1.4. Элемент 1.4.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3. (изменение)
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.
    3.4. Элемент 3.4.

То есть мы потеряли целостный смысл этих трех добавленных работ: новая функциональность - она нигде не видна. Соответственно отследить ход выполнения этой функциональности также будет проблематично (хотя и возможно).

Можно доработать СДР так: создать новый пункт (4) и собрать работы для реализации новой функциональности в этот пункт:

Код: [Выделить]

1. Подсистема 1.
    1.1. Элемент 1.1.
    1.2. Элемент 1.2.
    1.3. Элемент 1.3.
2. Подсистема 2.
    2.1. Элемент 2.1.
    2.2. Элемент 2.2.
    2.3. Элемент 2.3.
3. Подсистема 3.
    3.1. Элемент 3.1.
    3.2. Элемент 3.2.
    3.3. Элемент 3.3.
4. Новая функциональность
    1.4. Элемент 1.4.
    2.3. Элемент 2.3. (изменение)
    3.4. Элемент 3.4.
Но так я считаю тоже будет неправильно. Так как теперь СДР составлена путем смешения разных подходов.

Как же правильно построить СДР, чтобы совместить и подход по результату и функциональный подход?
Для поиска ответа я даже для себя перевел документ PMI Practice Standard for WBS. 2nd edition. Однако четкого ответа так и не нашел. Там сказано, что можно строить и так, и так. Но как это совместить - не ясно.

Дайте пожалуйста какие-нибудь советы.