Структурная декомпозиция это: Обзор структурной декомпозиции работ | Microsoft Docs

Содержание

Обзор структурной декомпозиции работ | Microsoft Docs

  • Статья
  • Чтение занимает 18 мин
  • Участники: 3

Были ли сведения на этой странице полезными?

Да Нет

Хотите оставить дополнительный отзыв?

Отзывы будут отправляться в корпорацию Майкрософт. Нажав кнопку «Отправить», вы разрешаете использовать свой отзыв для улучшения продуктов и служб Майкрософт. Политика конфиденциальности.

Отправить

В этой статье

Важно!

Dynamics 365 for Finance and Operations стало специализированным приложением, с помощью которого вы можете управлять определенными бизнес-функциями. Дополнительные сведения об этих изменениях см. в разделе Руководство по лицензированию Dynamics 365.

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

  • Описание разбивки или состава работы по задачам.
  • Расписание работы проекта.
  • Оцените стоимость каждой задачи.

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

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

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

Необходимые условия для создания WBS

Чтобы создать WBS, вы должны уметь составлять расписание работы и оценивать стоимость работ.

Условия для создания расписания работы

Чтобы использовать все возможности планирования функций WBS, выполните следующую настройку:

  1. Настройте календарь по умолчанию и календарь проекта:

    1. Перейдите Управление проектом и учет > Настройка > Параметры управления проектом и учета > Планирование. В поле Рабочий календарь по умолчанию укажите календарь по умолчанию. Это будет рабочий календарь по умолчанию для любого нового создаваемого проекта.
    2. Вы можете изменить календарь по умолчанию для конкретного проекта. Щелкните страницу сведений о проекте, а затем на экспресс-вкладке Проектная группа и планирование обновите поле Планирование календаря, выбрав другой календарь.
  2. Установите стандартные рабочие дни и часы работы. Календарь, который вы установили в качестве рабочего календаря для своего проекта, будет использоваться в WBS для определения следующей информации:

  • Рабочие дни и праздники
  • Количество рабочих часов в день

Чтобы настроить рабочие дни и часы работы для календаря или создать новый календарь, щелкните Администрация организации > Общие

> Календари.

Условия для оценки стоимости работ

Чтобы использовать все возможности оценки стоимости WBS, вы должны установить затраты и цены продажи для работников, категории труда, расходы, сборы и номенклатуры.

  • Чтобы настроить стоимость и цену продажи на рабочую силу, расходы и категории вознаграждения, щелкните Управление проектами и учет > Настройка > Цены.
  • Чтобы настроить стоимость и цену продажи номенклатур, используйте страницу Торговые соглашения для каждой номенклатуры на странице списка Выпущенные продукты в управлении информацией о продукте.

Создание WBS

Создание WBS включает три действия:

  1. Декомпозиция работы — создайте разбивку работы на управляемые части или задачи.
  2. Рабочий график — оцените время, необходимое для выполнения задачи, установите взаимозависимости задач и выберите даты начала и окончания для задач.
  3. Оценка затрат — оцените затраты на каждую задачу.

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

Декомпозиция работы

Создание разбивки или декомпозиции работы обычно является первым шагом в процессе создания WBS. Функциональность WBS поддерживает следующие основные конструкции для разбивки или декомпозиции работы.

Корневая задача проекта

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

Сводные задачи или задачи контейнера Суммарная задача — это задача, под которой находятся подзадачи или составляющие задачи. В сводной задачи нет своих усилий работы или стоимости. Вместо этого трудозатраты и стоимость суммарной задачи — это сумма трудозатрат и затрат на составляющие ее задачи. Самая ранняя дата составляющих задач используется как дата начала сводной задачи, самая последняя дата окончания составляющей задачи используется как дата окончания. Имя сводной задачи можно редактировать, но свойства расписания (усилия, даты и длительность) нельзя изменить. При удалении сводной также удаляются все ее составляющие задачи.

Задачи листового узла Задача листового узла представляет собой наиболее детализированный рабочий пакет проекта. Листовой узел — это расчетное усилие, плановое количество ресурсов, запланированные даты начала и окончания и продолжительность.

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

Новая задача Любая новая задача, которую вы создаете, автоматически добавляется в корневой узел, и этой задаче автоматически присваивается номер WBS. Номер WBS представляет уровень задачи в иерархии. Для задач на первом уровне под корневой задачей проекта используется схема нумерации 1, 2, 3, и т. д. Для задач ниже первого уровня используется схема нумерации 1.1, 1.2, 1.3, и т. д. Для каждого уровня, который добавляется под предыдущим, добавляется новая пунктирная серия чисел.

В настоящее время вы не можете настроить нумерацию WBS.

Понижение уровня задачи Когда вы понижаете уровень задачи, она становится дочерним элементом задачи, которая ей предшествует. Номер WBS новой дочерней задачи автоматически пересчитывается на основе номера WBS ее нового родительского элемента. Родительская задача теперь является сводной или контейнерной задачей и, следовательно, становится совокупностью составляющих ее задач.

Примечание

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

Повышение уровня задачи Когда вы повышаете уровень задачи, она больше не входит в состав родительской задачи. Номер WBS этой задачи автоматически пересчитывается, чтобы отразить новый уровень задачи в иерархии. Усилия, стоимость и даты предыдущей родительской задачи пересчитываются, чтобы они исключали эту задачу.

Перемещение вверх и вниз Когда вы нажимаете Переместить вверх и Переместить вниз, вы меняете положение задачи в родительской иерархии. Положение задачи не влияет на усилия, стоимость, даты и длительность задачи. Однако номер WBS этой задачи автоматически пересчитывается, чтобы отразить новое положение задачи.

Оценка расписания

Оценка расписания обычно является вторым шагом в создании WBS. Рекомендуется выполнять оценку расписания после создания задач. На странице Структурная декомпозиция работ в Finance есть два раздела. Верхняя панель предназначена для оценки расписания, а нижняя панель содержит вкладку

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

Планирование задач Следующие факторы определяют планирование задач листового узла:

  • Предшественники
  • Усилия
  • Количество ресурсов
  • даты начала и окончания;

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

Правила планирования Когда включена поддержка автоматического планирования, следующие правила применяются к планированию задач для задач листовых узлов:

  • Даты начала и окончания задачи должны быть рабочими днями, в соответствии с календарем планирования проекта.
  • Дата начала задачи, у которой есть предшественник, задается как последняя дата окончания ее предшественников.
  • Усилия на выполнение задачи автоматически рассчитываются следующим образом:

Число людей × длительность × количество часов в стандартном рабочем дне календаря проекта.

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

Примечание

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

Исправление ошибок расписания Когда включена поддержка автоматического планирования, ошибки планирования маловероятны. Однако, если вы отключите автоматическое планирование и затем снова включите его позже, в WBS могут появиться значки ошибок планирования.

Исправление ошибок планирования по задачам Если дважды щелкнуть значок ошибки расписания для конкретной задачи, в диалоговом окне отобразятся все ошибки планирования для этой задачи. Вы можете решить, какие ошибки планирования исправить для задачи.

Исправление всех ошибок планирования Если вы хотите, чтобы Finance исправило все ошибки планирования в WBS, на панели действий щелкните Устранить все несоответствия в расписании.

Примечание

Эта функция может вызвать значительные модификации WBS. Ошибки исправляются в следующем порядке:

  1. Расчетное усилие по всем задачам изменяется так, чтобы оно равнялось загрузке, определенной в календаре проекта.
  2. Дата начала каждой задачи изменяется так, чтобы задача запускалась после завершения всех предшествующих задач.
  3. Дата начала каждой задачи изменяется, чтобы удалить пробелы в датах начала предшествующих задач.

Оценка затрат

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

Примечание

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

  • Трудозатраты
  • Номенклатура или материал
  • Расходы

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

Тип транзакции Промежуточная накладная используется для записи контрактной стоимости продажи в проекте с фиксированной стоимостью. Этот тип транзакции также не учитывается при оценке затрат.

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

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

Оценка расходов и материальных затрат На вкладке Ориентировочные затраты и доход также можно оценить расходы и материальные затраты для задачи, если вам требуются оценки.

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

Отслеживание прогресса в WBS

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

В Finance есть три представления для WBS проекта: представление планирования, представление отслеживания усилий и представление отслеживания затрат.

Представление планирования

В представлении «Планирование» отображается плановая или базовая оценка расписания и информация о затратах. Хотя для проекта WBS нет функций для отслеживания версии и базовых показателей, значения в этом представлении предназначены для представления базовой версии. В разделах «Оценка расписания» и «Оценка стоимости» этой темы описывается это представление и то, как оно используется для создания WBS.

Представление отслеживания усилий

Представление «Отслеживание усилий» отображает отслеживание хода выполнения задач в WBS. Здесь сравниваются накопленные фактические часы трудозатрат для задачи с запланированными часами трудозатрат. Следующие формулы предоставляют значения в представлении отслеживания усилий:

  • Процент хода выполнения = Фактические усилия по настоящее время ÷ Запланированные усилия для задачи
  • Оставшиеся усилия (также известные как «Оценка до завершения» [ETC]) = Запланированные усилия – Фактические усилия на сегодняшний день
  • Оценка при завершении (EAC) = Оставшиеся усилия + Фактические усилия по настоящее время
  • Отклонение от ожидаемых усилий = Запланированные усилия — EAC

В представлении отслеживания трудозатрат отображается прогноз отклонения трудозатрат для задачи в зависимости от того, больше ли EAC запланированных трудозатрат или меньше:

  • Если EAC превышает запланированные усилия, прогнозируется, что на выполнение задачи потребуется больше времени, чем запланировано первоначально, и расписание не соблюдается (опоздание).
  • Если EAC меньше запланированных усилий, прогнозируется, что на выполнение задачи потребуется меньше времени, чем запланировано первоначально, и расписание не соблюдается (обгон).

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

Существует два способа, которыми руководители проекта могут изменить усилия по задачам:

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

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

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

  1. Рассчитываются ПОПЗ, ETC и процент выполнения для задачи.
  2. Новое значение ПОПЗ распространяется в дочерние задачи в той же пропорции, что и первоначальная сумма ПОПЗ.
  3. Рассчитывается новый ПОПЗ для каждой задачи листового узла.
  4. Оставшиеся усилия и процент хода выполнения пересчитываются для всех затронутых дочерних задач на основе нового значения ПОПЗ. Также пересчитывается отклонение усилий для задач.
  5. ПОПЗ суммарных задач также пересчитывается из листовых узлов.

Нажмите Развернуть до уровня в представлении отслеживания усилий, чтобы задать уровень, на котором следует отслеживать и поддерживать вашу WBS. WBS автоматически расширяется до этого уровня в представлении отслеживания усилий, когда вы его открываете.

Представление отслеживания стоимости

В представлении «Отслеживание затрат» отображается отслеживание потребления затрат для задачи. В этом представлении фактические затраты, израсходованные по задаче на текущий момент, сравниваются с плановыми затратами по задаче. Следующие формулы предоставляют значения в представлении отслеживания затрат:

  • Потребленный процент стоимости = Фактическая стоимость на сегодняшний день ÷ Запланированная стоимость для задачи
  • Стоимость до завершения (CTC) = Запланированная стоимость — Фактическая стоимость по настоящее время
  • Полная оценка (ПОПЗ) = CTC + Фактическая стоимость на сегодняшний день
  • Ожидаемое отклонение стоимости = Запланированная стоимость — ПОПЗ

В представлении отслеживания затрат отображается прогноз отклонения затрат для задачи в зависимости от того, больше ли ПОПЗ запланированных затрат или меньше:

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

Изменение прогноза стоимости руководителем проекта Руководители проектов должны использовать CTC для корректировки исходной оценки затрат на задачу. Менеджер проекта может изменить значение CTC до стоимости, необходимой для выполнения задачи. Если вы изменяете значение CTC, CTC задачи, ПОПЗ, и процент потребленных затрат, а также прогнозируемое отклонение затрат по задаче пересчитываются. ПОПЗ, ETC и процент потребленной стоимости сводных задач также пересчитывается, и прогнозируемое отклонение по затратам обновляется.

Примечание

Когда вы пересматриваете трудозатраты для задачи WBS в представлении «Отслеживание трудозатрат», CTC задачи, ПОПЗ, процент потребленных затрат и прогнозируемое отклонение затрат пересчитываются в представлении «Отслеживание затрат». Однако корректировки стоимости не влияют на значения в представлении отслеживания усилий, поскольку стоимость по типу транзакции (труд, материал или расходы) или категории проекта не изменяется.

Пересмотр прогноза затрат по суммарным задачам Вы можете пересмотреть затраты на суммарные задачи, и расчеты будут выполняться автоматически в следующем порядке:

  1. ПОПЗ, CTC и процент затрат, затраченных на задачу, пересчитываются.
  2. Новое значение ПОПЗ распространяется в дочерние задачи в той же пропорции, что и первоначальное значение ПОПЗ для задач.
  3. Рассчитывается новый ПОПЗ для каждой задачи.
  4. CTS и процент потребленных затрат пересчитываются для затронутых дочерних задач на основе значения EAC. Также пересчитывается отклонение затрат для задач.
  5. EAC для всех суммарных задач пересчитывается на основе этого изменения.

Нажмите Развернуть до уровня в представлении отслеживания затрат, чтобы задать уровень, на котором следует отслеживать и поддерживать вашу WBS. WBS автоматически расширяется до этого уровня в представлении отслеживания затрат, когда вы его открываете.

Управление вырученной стоимостью

Вы можете использовать метод вырученной стоимости (EVM) для отслеживания хода выполнения проекта. Вы можете просмотреть показатели вырученной стоимости объема в Ролевом центре менеджера проекта. Компонент диаграммы вырученной стоимости показывает повременные значения плановой стоимости и фактических затрат. Вырученная стоимость на текущую дату отображается в виде баллов. Повременные данные по вырученной стоимости в настоящее время недоступны.

Временной этап на диаграмме вырученной стоимости отображается по неделям или месяцам. В этом разделе описаны три основы EVM: плановая стоимость, вырученная стоимость и фактическая стоимость.

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

В Finance используются правило выручки 0:100 при построении плановой стоимости. В соответствии с этим правилом значение задачи разносится в задачу на дату ее окончания. Значение не публикуется, пока задача не будет выполнена на 100 процентов.

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

Вырученная стоимость Теория EVM утверждает, что график вырученной стоимости представляет собой скорость, с которой команда проекта фактически зарабатывает на проекте.

В Finance используются правило выручки 0:100 при построении вырученной стоимости. В соответствии с этим правилом значение задачи разносится в задачу на дату ее окончания. Значение не публикуется, пока задача не будет выполнена на 100 процентов.

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

Примечание

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

Фактическая стоимость Теория EVM утверждает, что график фактических затрат представляет собой скорость, с которой деньги тратятся на проект.

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

Как использовать концепции плановой стоимости, вырученной стоимости и фактических затрат

Отклонение от расписания Во время планирования вы создаете прогноз работы на временной шкале. Таким образом, плановая стоимость — это скорость, с которой, по мнению планировщиков, работа над проектом будет завершена. После того, как проект выполняется, работа завершена, и проект окупается. Сравнивая плановую стоимость с вырученной стоимостью, вы можете увидеть, как продвигается работа над проектом. Результат этого сравнения называется отклонением от расписания.

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

Если плановая стоимость за период меньше, чем вырученная стоимость, объем работы, выполненной по проекту, больше запланированного. Таким образом, проект опережает график. У этого времени выполнения заказа также денежная оценка.

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

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

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

Шаблоны WBS

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

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

Сохранение WBS проекта в качестве шаблона

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

Импорт шаблона WBS в WBS проекта

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

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

Различия между WBS проекта и шаблоном WBS

  • У задач в шаблонах WBS нет дат начала и окончания.

Для шаблонов WBS не заданы рабочие и нерабочие дни.

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

Календарь планирования по умолчанию используется только для определения часов стандартного рабочего дня.

  • Взаимосвязь предшественника не копируется в шаблон WBS.

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

  • Строка оценки затрат на рабочую силу создается автоматически при создании задачи в шаблоне WBS. Цена продажи и сумма затрат копируются из выбранного работника.

Затраты и затраты на номенклатуру можно создавать вручную, как и в WBS проекта.

  • Ошибки планирования отображаются, если есть отклонения от следующей формулы:

Усилия = Количество ресурсов × Продолжительность × Количество часов в стандартном рабочем дне

Вы можете исправить все ошибки планирования одновременно, нажав Исправить все ошибки планирования.

Кроме того, вы можете исправить ошибки планирования отдельно, щелкнув значок предупреждения для каждой задачи.

Структурная декомпозиция работ или WBS иерархия проекта

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

  • в английском языке – Work Breakdown Structure (или WBS-структура)
  • в русском – структурная декомпозиция работ проекта (СДР) или иерархическая структура работ (ИСР).

Суть декомпозиции – в разделении (разбиении) процесса на части по тому или иному признаку: по типу производимого во время работ продукта, по функциональности, по этапам жизненного цикла и т.д.. Важно, чтобы такое разделение выделяло достаточно простые составляющие – более управляемые элементы, помогающие лучше контролировать реализацию задач и достижение цели. Однако иерархическая структура работ отличается от просто графика реализации, от документа, аналогичного плану проекта и от перечня вех. Чем именно отличается, рассмотрим в статье.

Содержание статьи

Определение и характеристики WBS

Структурной декомпозицией работ (Work Breakdown Structure) называют представление проекта, исполненное в виде иерархической структуры работ, что достигается посредством последовательной декомпозиции. Инструмент направлен на детальное планирование, оценку стоимости, определение и распределение персональной ответственности исполнителей и т. д. – то есть, на основные работы и результаты, определяющие содержание проекта.

В Work Breakdown Structure элементами проекта могу быть услуга, продукт, работа или группа работ (wbs group). Каждый нижестоящий уровень в иерархии детализирует какой-либо элемент вышестоящего уровня, но при этом должны быть соблюдены следующие принципы:

  1. Принцип «Правильного дерева». Идея в том, чтобы у каждого зависимого элемента (у каждой «ветки» или, при ещё более дробном разделении, – у каждого «листа») был только один родительский элемент.
  2. Принцип полноты и логической стройности. В СДР должны учитываться все элементы проекта, однако ничего не должно дублироваться.
  3. Принцип единства критерия. Процесс декомпозиции должен происходить по одному критерию, поэтому, например, нельзя вперемежку работать сразу и с продуктом, и с функциональными задачами.
  4. Принцип глубины СДР. Разделение должно производиться до тех пор, пока получившаяся структура не будет легко управляемой и контролируемой. Чаще всего этот процесс заканчивается при структурировании до уровня элементарной работы – такой, которую способен выполнить один сотрудник, или которую можно контролировать как отдельную единицу.

Воплощение данных принципов в проекте приводит к тому, что иерархическая структура работ приобретает определённые характеристики, а именно:

  • всегда описывает содержание работ с необходимой (достаточной) точностью,
  • охватывает весь объём – 100% – работ по проекту (если какие работы не входят в СДР, значит, они выпадают и из содержания),
  • структура декомпозируется на иерархически выстроенные элементы (пакеты, субпакеты и т. д.)., причём верхние уровни соответствуют основным этапам проекта, и по мере приближение к нижним уровням определение работ всё более детализируется,
  • блоки работ в структуре автономны,
  • работы имеют измеримый (либо сравнимый) результат, а каждый блок работ – исходный результат (при этом легко оцениваются время и расходы),
  • стартовые и завершающие мероприятия определяются чётко и однозначно.

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

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

Алгоритм построения иерархической структуры работ

На практике в процессе формирования Work Breakdown Structure нужно уметь правильно поставить вопросы и грамотно организовать процесс структуризации. Для этого на первоначальном этапе предлагаются различные алгоритмические варианты, которые описывают нисходящий метод создания СДР.

Пример № 1:

  • Взяв за основу определение области проектного охвата, выписываются цели проекта.
  • В строке (по горизонтали) перечисляются исходные результаты, получение которых нужно для достижения целей.
  • Для каждого отдельного исходного результата определяются необходимые для его обеспечения работы или ключевые блоки.
  • В вертикальном столбике они детализируются до необходимой степени детальности.
  • В работу над проектом вовлекаются участники команды и все заинтересованные стороны. (Как вариант – разработка СДР производится сразу совместными усилиями участников).

Пример № 2 с использованием стикеров и флипчарта:

  • У участников проекта, работающих в команде, нужно узнать, что, по их мнению, необходимо для реализации проекта.
  • Все ответы на этот вопрос участники проекта записывают на стикерах.
  • Близкие и совпадающие ответы о наиболее значимых задачах группируются в стопки или вывешиваются на демонстрационной доске в тематических колонках.
  • Те задачи, которые не попали ни в какую колонку, клеятся отдельно.
  • Колонкам или стопкам со сгруппированными задачами даётся наименования, которые записываются на флипчарт (с соответствующим набором стикеров под каждой категорией).

Далее конечные результаты разбиваются на операции, причём этот цикл продолжается до тех пор, пока не появляется возможность отслеживать и контролировать отдельные задачи. Важно, чтобы один пакет работ содержал один результат.

Если в создании Work Breakdown Structure используются программы управления проектами – например, самая распространённая MS Project или её аналоги – то:

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

Для встраивания СДР в график проекта нужно добавить следующую информацию в ранее созданную иерархическую структуру:

  • Продолжительность, или полное время выполнения каждой задачи.
  • Зависимость и взаимосвязь между задачами, которую можно установить с помощью сетевой диаграммы.
  • Ограничения для каждой задачи (если есть).
  • Даты начала и конца выполнения задачи (при указании параметра длительности программа эти даты вычисляет автоматически).
  • Наименования ресурсов.

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

WBS как инструмент управления в различных проектных проявлениях

Инструмент структурной декомпозиции можно эффективно применять в различных проектных проявлениях:

  • Для определения проектных результатов.
  • Для организации коммуникаций. WBS помогает осуществлять направленную передачу информации с учётом задачи и ответственности участника за её исполнение.
  • Для документирования и отчётности. Документальное отражение WBS проявляется в общей терминологии, в формировании бюджета «сверху-вниз», в составлении отдельной отчётности, соответствующей структуре WBS.
  • Для оптимизации управления и типизации уровней. Так в тематической литературе рекомендуют использовать не более 6 уровней, где верхние 3 предназначены для информации уровня заказчика, а нижние 3 – уровня исполнителя. Но, в первую очередь, глубина детализации должна быть ориентирована на сложность и размер проекта.

Иерархическая структура работ может как разрабатываться «с нуля», так и включать компоненты ранее созданных структур WBS, которые берутся из предыдущих аналогичных проектов, шаблонных стандартизированных вариантов, используемых организацией с учётом успешности применения их в прошлом в типовых условиях.

Структурная декомпозиция работ проекта — Студопедия

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

Структурная декомпозиция работ (СДР или WBS — Work Breakdown Structure) – это представление проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.

Благодаря структурной декомпозиции работ менеджер проекта имеет:

· точное описание содержания работ;


· точное определение объема работ;

· измеримый результат выполнения работ.

Предназначение СДР

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

СДР обеспечивает выявление работ, необходимых для достижения целей проекта. Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку выполненных объемов работ, освоенных денег и выполнения по срокам. На нижних уровнях пакетам работ соответствуют сравнительно меньшие объемы работ. Это упрощает оценку процента выполнения и дает возможность более четко определять действия, необходимые для достижения целей проекта.

Разработка СДР имеет две основные цели:

1. обеспечение планирования всех необходимых работ проекта,

2. обеспечение отсутствия работ, не связанных с реализацией проекта.

Для руководителя проекта важны обе эти цели. Если в плане отсутствуют необходимые работы, проект будет задержан, бюджет, скорее всего, будет превышен. Если выполняются работы, не относящиеся к данному проекту – деньги заказчика тратятся нецелевым образом. Если СДР не объединяет обе эти цели, проект может потерпеть неудачу.


На основе СДР выполняются следующие процессы:

1. определение работ,

2. планирование ресурсов,

3. оценка стоимости,

4. бюджетирование,

5. определение рисков.

Рис. 1 Взаимодействие СДР с процессами реализации проекта (PMBOK Guide)

Таким образом, СДР является основой:

· Комплексного план-графика проекта – СДР обеспечивает основу для планирования объемов работ, стоимости, сроков и рисков. С помощью СДР работы структурируются и непосредственно связываются с графиком, а ресурсы распределяются и отслеживаются. При изменении содержания проекта СДР должна быть откорректирована. В рамках программных продуктов она также обеспечивает средство интеграции всех данных.

· Отчетности о выполнении проекта – с помощью СДР определяется состояние проекта и выдается в различные формы отчетности. Например, по стадиям жизненного цикла проекта; по результатам; по пакетам работ. Отчеты могут содержать данные по стоимости, срокам, рискам, объему, трудоемкости и качеству выполняющегося проекта или по сравнению с предыдущими аналогичными проектами (с такой же структурой).

· Комплексного контроля изменений – СДР обеспечивает идентификацию соответствующих точек контроля, которые используются для упрощения обмена информацией и контроля результатов.

· Управления содержанием проекта – процесс разработки СДР способствует формированию концептуального целостного представления об объекте проекта.


· Организации взаимодействия между участниками проекта – СДР позволяет организовать направленную передачу информации между руководителем и участниками проекта на всех стадиях его жизненного цикла, с учетом принятых обязанностей и ответственности участников.

· Формирования организационной структуры – с помощью СДР можно связать определенный объем работ с элементом организационной структуры, субподрядчиками или отдельными исполнителями. Как только определяются работы, отдельные исполнители (включая субподрядчиков) назначаются ответственными за выполнение определенных элементов СДР в рамках назначенных бюджетов и определенных сроков выполнения.

2. Структурная декомпозиция работ. Разработка плана проекта

Похожие главы из других работ:

Анализ организации ООО «Производственник»

3. Декомпозиция процесса управления

Рисунок 3. Структура макроподсистем управления ООО «Производственник» Мы рассматриваем ООО « Производственник» как сложную экономическую макросистему, в которой выделяются составные части — макроподсистемы…

Деятельность структурного подразделения железной дороги

2. СТРУКТУРНАЯ СХЕМА УПРАВЛЕНИЯ ПРЕДПРИЯТИЕМ

ТЦФТО является структурным подразделением железной дороги — филиала открытого акционерного общества «Российские железные дороги». ТЦФТО в своем составе имеет: технологический центр по обработке перевозочных документов (ТехПД)…

Изучение сущности системного подхода в теории организации

2.1 Структурная схема организации

Рисунок…

Кадровый потенциал предприятия: оценка и развитие

1.1 Структурная характеристика кадров предприятия

Категория «персонал предприятия» характеризует кадровый потенциал, трудовые и человеческие ресурсы производства. Трудовые ресурсы это трудоспособная часть населения, которая, обладая физическими и интеллектуальными возможностями…

Моделирование бизнес-процессов на примере ООО «НПГ «Сады Придонья»

2.4 Декомпозиция контекстной диаграммы

Таблица 2…

Основы менеджмента

2.3 Декомпозиция целей

организационный управление цель Основываясь на главных свойствах целей, развертываемости и подчиненности, конечная цель раскладывается на составляющие подцели, таким образом, чтобы коньюнкция этих подцелей определялась в конечную цель…

Основы планирования проекта. Разработка содержания проекта и предварительного календарного плана

2.3 Разработка иерархической структуры работ (дерево работ)

Структура разбиения работ проекта (СРР) или WBS (Work Breakdown Structure) представляет собой инструмент, который позволяет разбить проект на составные части. Декомпозиция работ — это основа планирования проектов и один из важнейших методов…

Планирование выпуска продукции

1.2 Декомпозиция цели системы на функции

Декомпозиция цели системы на функции — это деление цели на функции системы и подсистем и изучение их, в результате чего получается древовидная иерархическая структура функций, исследование которых позволяет изучить систему…

Процессный подход в управлении

1.2 Ресурсная база и декомпозиция процесса

К ресурсам процесса могут относиться: информация, персонал, оборудование, программное обеспечение, инфраструктура, среда, транспорт, связь и пр…

Процессный подход к управлению

1.2 Ресурсная база и декомпозиция процесса

К ресурсам процесса могут относиться: информация, персонал, оборудование, программное обеспечение, инфраструктура, среда, транспорт, связь и пр…

Системный анализ магазина «Бензо-Мото-Вело»

7. Декомпозиция по методологии IDEFO

Размещено на http://www.allbest…

Стратегическое управление в условиях рынка

2.6 Структурная напряженность

В целом по «Газпрому» коэффициент структурной напряженности составляет около 7 единиц, в то время как максимально допустимым значением считается 1,3. Климов А.А…

Структуризация

1.3. Понятия «декомпозиция» и «критерии декомпозиции»

Декомпозиция — это разбиение объекта на составные части. Критерий декомпозиции — это характеристика, на основе которой производится разбиение. Рассмотрим эти понятия на примере структуризации шаров…

Сущность тектологии

3.1 Количественная и структурная устойчивость

Если воздух не насыщен паром, капля подвергается испарению, теряет свои элементы в окружающую среду. За некоторый промежуток времени она при этих условиях должна совсем исчезнуть: кризис разрушения данного комплекса. Комплекс…

Управление проектом, создание системы информационной безопасности

11. Структурная схема организации

Структурная схема организации содержит в себе совокупность должностных лиц, участвующих в проекте по созданию КСЗИ, и выполняемых ими функций в процессе этой деятельности. В структурную схему входят: 1. Начальник отдела по защите информации 2…

Структура декомпозиции работ

Структура декомпозиции работ

Итак, мы определили результаты, которые должны быть достигнуты по завершении проекта, и согласовали их со всеми заинтересованными лицами. Однако мы не можем планировать проект, руководствуясь лишь перечнем этих результатов. Чтобы спланировать проект, необходимо определить, какие конкретные работы должны быть выполнены для достижения этих результатов, т. е. для успешного завершения проекта. Для этого и используется структура декомпозиции работ (СДР, или Work Breakdown Structure, WBS).

WBS является ключевым элементом плана проекта. Без нее невозможно определить работу, которую необходимо сделать для выполнения проекта, а значит невозможно определить ни стоимость проекта, ни его календарный план. А без этого нельзя рассчитать, какие ресурсы потребуются для выполнения проекта и в какое время эти ресурсы должны быть доступны. Средства, выделенные на проект, будут получены вовремя только при условии тщательной проработки детального, поэтапного бюджета проекта. Наконец, не имея представления о том, какие работы должны быть выполнены в ходе проекта, невозможно удовлетворительным образом управлять рисками. Для решения всех перечисленных выше задач и необходима WBS.

В «Руководстве по управлению проектами» (Guide to the Project Management Body of Knowledge, http://www.pmi.org/publictn/pmboktoc.htm) WBS определяется как «ориентированное на результаты группирование компонентов проекта, которое определяет, какие работы должны быть произведены в проекте. Работы, не включенные в WBS, не входят в рамки проекта». Из этого определения мы можем извлечь метод выявления работ, которые надлежит выполнить для получения требуемых результатов проекта. Как мы увидим ниже, этот метод во многих проектах позволяет определить около 90% необходимых работ.

Методика

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

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

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

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

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

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

Пример: проект «Аполлон»

В 60-е годы в США был реализован проект полета человека на Луну с последующим возвращением на Землю. В этом очень крупном проекте участвовали многие тысячи сотрудников. Руководитель проекта, о котором идет речь, жил в Вашингтоне и тратил большую часть своего времени на взаимодействие с Конгрессом США и другими правительственными структурами.

Когда программа «Аполлон» достигла своего апогея, в ее реализации единовременно оказались задействованы 40 тыс. человек. В эту программу входил проект создания двигателя первой ступени ракеты-носителя «Сатурн 5». У проекта был свой руководитель и множество сотрудников. В проекте разработки двигателя ракеты-носителя было задействовано несколько организаций, расположенных в различных частях страны. В рамках проекта, над которым трудились несколько тысяч человек, были другие проекты: проект тестирования механизмов, проект топливных систем, проект систем охлаждения и т. д. и у каждого проекта был свой руководитель.

Хотя объем работ в рамках проекта создания двигателя ракеты-носителя был весьма и весьма значителен, речь идет лишь о малой части программы «Аполлон». Поэтому в зависимости от места, занимаемого в иерархии руководителем какой-либо части программы, мы можем считать его менеджером программы, менеджером проекта или даже менеджером подпроекта.

Методика в подробностях

Подготовку структуры декомпозиции работ (WBS) можно считать законченной, когда определены мелкие индивидуальные части (элементарные) работы. Ответственность за каждую элементарную работу должна быть поручена одному и только одному члену команды проекта. Очень важно понять, что первоочередная задача составления WBS — разделить проект на подпроекты до той степени детализации, когда появится возможность распределить элементарные работы.

Если проект большой, WBS может иметь довольно общий характер. Можно остановиться на самом нижнем уровне, который отслеживает руководитель проекта. Этот уровень, напомним, принято называть пакетом работ. Следует учитывать, что начиная с этого уровня другие менеджеры, занятые на проекте, должны осуществить более подробное разделение проекта на части (подпроекты) до уровня элементарных работ.

На самом нижнем уровне WBS должно быть описание элементарной работы, которая может быть выполнена одним человеком (или группой людей). Если этот человек (или группа) собираются выполнять работу, а не руководить ее выполнением, этот уровень может быть признан самым нижним уровнем WBS (в отличие от более высокого уровня — пакета работ, — определение которому дается выше). Этот же уровень называется уровнем задания или конкретных действий.

Вышеприведенные термины еще не вполне устоялись, что отразилось и на их трактовке в «Руководстве по управлению проектами», где подход к построению WBS отделен от определения заданий и элементарных работ. (При этом самым нижним уровнем WBS считается пакет работ — самый нижний уровень, который менеджер проекта должен держать под своим прямым контролем. Отдельно от построения WBS в «Руководстве» описано дальнейшее деление пакетов работ на более низкие уровни элементарных работ вплоть до привязки к конкретным исполнителям конкретных действий, которые в свою очередь могут быть разбиты на задания.) В «Руководстве» данный вопрос чрезмерно усложнен. Я не думаю, что в мире много менеджеров проектов, которые не используют термины «задание», «конкретные действия» и «элементарная работа» как взаимозаменяемые. Поэтому меня всегда несколько огорчало, что «Руководство» пытается провести это необязательное разграничение. Было бы более логично, если бы WBS начиналась с уровня проекта, разбиваемого на подпроекты, и каждый подпроект разбивался бы на подподпроекты более низкого уровня до тех пор, пока бы не был достигнут уровень элементарной работы. Большинство менеджеров проектов составляет WBS, исходя из этих позиций, поэтому попытки ввести дополнительные разграничения могут привести к неразберихе.

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

Системный подход к иерархической структуре декомпозиции работ

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

Крайне важно, чтобы на каждом более низком уровне декомпозиции был назначен один и только один ответственный работник, вне зависимости от того, идет ли речь о пакете работ или элементарной работе. Наконец, указанная работа проделана, WBS построена. Мы определили вроде бы всю работу по проекту. На самом деле нам удалось определить примерно 90% от общего объема работ, которые реально необходимо проделать. Теперь нужно выявить, что нам еще, возможно, предстоит сделать в проекте.

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

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

Системный анализ позволяет сделать уточнения в определении работы, которую необходимо выполнить в рамках проекта. Каждый человек, отвечающий за выполнение элементарной работы, будет просматривать другие работы в поисках того, что необходимо для выполнения его работы. Он также будет изучать другие части проекта, которым должны быть переданы выходные элементы его работы. Каждый входной и выходной элемент будет рассмотрен, по крайней мере, два раза. Все входные элементы должны исходить от чего-то внутри проекта или из внешнего источника. Все выходные элементы должны либо быть переданы в другую элементарную работу проекта, либо непосредственно являться частью результатов проекта.

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

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

Что такое иерархическая структура работ и как с её помощью эффективно реализовать проект


Команда наглядно видит, как решение каждой задачи приближает достижение конечного результата.

ИСР обеспечивает эффективное планирование, помогает оценить загруженность команды на разных этапах и корректно закрепить задачи за участниками проекта.

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

Видно, на чём нужно заострить внимание, как распределить ресурсы, как заказчик представляет себе поставленные перед командой задачи и что ставит в приоритет.

ИСР становится основой для последующих задач, добавления и корректировки результатов. Может стать шаблоном для типовых проектов.

Кроме ИСР существуют и другие инструменты — их выбор зависит от условий, в которых предстоит реализовать цель.

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

ИСР более гибкий с этой точки зрения инструмент, но если нужно ориентироваться на дедлайны, то больше подойдёт метод критического пути.


Пункт очевидный, но с нюансом: следует охватить весь спектр нужных задач, при этом оставить за рамками ИСР несоответствующие и посторонние.

Например, в планировании ремонта по ИСР нужно включить закупку материалов, но не нужно — «попросить скидку у поставщика», «ещё раз попросить скидку».

Также не нужно дублировать задачи и слишком детально прописывать шаги.

Здесь главное «что», а не «как» — это поможет концентрироваться на результатах. Например, сравним «составить план на разработку концепции» и «разработанная концепция». Последнее, более ёмкое и краткое, акцентирует внимание на полученном результате — смещает фокус в правильное русло.

Этого достаточно для большинства проектов. Ориентируясь на этот принцип, легче вычленять главное и делать упор на результат. Определить, где остановить декомпозицию, поможет положительный ответ на вопрос, можно ли поставить одного исполнителя на конкретный пакет работ. Если один человек с ним не справится ― разбивайте задачи дальше.

Каждый пакет работ закрепляется за конкретной командой или за отдельным ответственным. Если сформировать ИСР верно, обязанности всем будут понятны и не будут дублироваться.

Декомпозиция проекта — Энциклопедия по экономике

Помимо декомпозиции проекта, необходимо определить работы и процессы,  [c.22]

Декомпозиция представляет собой творческий процесс и может быть выполнена на основании состава фаз проекта, структуры продукта проекта, состава выполняемых работ и т. д. На практике часто удачную декомпозицию проекта можно получить, сочетая разные принципы декомпозиции (например, структура продукта в сочетании с характерными фазами проекта).  [c.212]


Проверить корректность декомпозиции проекта при помощи анализа ответов на следующие вопросы.  [c.212]

В чем состоит суть структуризации (декомпозиции) проекта  [c.63]

Организуя процесс разработки программного изделия, необходимо иметь в виду основную идею иерархической декомпозиции проекта, при которой всегда сохраняется завершенность (с точки зрения учета всех аспектов проектирования) на различных этапах все более увеличивающейся детализации. Декомпозиция проекта является вторым этапом в цепочке, включающей три этапа декомпозиции, следующих друг за другом. Первый этап — декомпозиция плана, третий—программная декомпозиция, часто называемая программированием сверху вниз или нисходящим программированием.  [c.87]

При тщательном выполнении декомпозиции проекта удается выделить задачи анализа осуществимости проекта, внешнего и внутреннего проектирования, программирования и компоновки. При этом предполагается вертикальная организационная структура группы разработки, в которой предусматривается старший управленческий персонал, ориентированный на выполнение анализа осуществимости проекта (т. е. определяющий назначение программного изделия и требования к нему), а также старший технический персонал, создающий внешние и внутренние проекты, и младший технический персонал, участвующий в написании, отладке и компоновке программ. Такое разделение труда способствует проявлению творческих способностей в любой фазе разработки, помогает избежать излишних затрат ресурсов на заведомо бесперспективные проекты, открывает для сотрудников наиболее заманчивые пути административного и технического роста и, кроме того, представляет возможность контроля за упорядоченным переходом от одной фазы проекта к другой.  [c.87]


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

Концепция бригады главного программиста хорошо вписывается в методологию, излагаемую в данной книге. Библиотека поддержки разработки является хорошей иллюстрацией методов конфигурационного управления на уровне проекта. Структурное программирование удовлетворяет многим требованиям методологии проектирования, которые упоминаются в этой книге. Нисходящее проектирование, называемое также программированием сверху вниз, является фактически постепенной детализацией описаний функциональной структуры на уровнях более простых функций до тех пор, пока, наконец, не будет достигнут уровень собственно операторов языка программирования [14]. В ходе этого процесса фактически осуществляется декомпозиция проекта, описанная в предыдущей главе. Как заметил Бейкер [39], один из недостатков работы бригад главного программиста заключается в отсутствии подробных описаний функциональной структуры, которые отражали бы все внешние аспекты системы, не затрагивая внутренней структуры проекта. Ясно, что речь здесь идет о внешних спецификациях, рассмотренных в гл. 2. Бригада главного программиста, в составе которой предусмотрена должность руководителя проек-  [c.91]

Деятельность группы поддержки достигает первого максимума после передачи плана поддержки на рассмотрение в другие группы (рис. 11.2). Как видно из рис. 11.3, группа поддержки одновременно занята подготовкой рекламного материала, проверкой внешних спецификаций и изучением плана выпуска документов. В этот период важно установить определенную приоритетность работ, чтобы уложиться в запланированные сроки. Лучше всего выполнять их по очереди, однако это может значительно увеличить время проектирования. Хотя календарные планы отдельных проектов в чем-то отличаются друг от друга, группа поддержки всегда стремится выполнять свои работы в следующем порядке , сначала изучить внешние спецификации, затем проверить план выпуска документов, отреагировать на замечания к плану поддержки и, наконец, подготовить рекламный материал. Эта очередность работ наилучшим образом соответствует хорошему стилю планирования и требованиям декомпозиции проекта.  [c.183]

В соответствии с формой, представленной в предыдущем разделе, ниже дается описание информации, которая должна присутствовать в любом соглашении о требованиях. Все последующие упоминания о соглашении о требованиях (СТ) имеют в виду соглашение о требованиях, разработанное в соответствии с данным разделом. Описываемый подход предполагает также декомпозицию проекта в соответствии с табл. 13.2 и дальнейшую детализацию, отражаемую во внешней спецификации изделия согласно разд. 15.1. Материал, следующий вплоть до заголовка Календарный план , пронумерован, озаглавлен и напечатан так же, как в СТ, но с одним исключением обозначения Ок, Ч, Об и 3 указывают уровень детализации.  [c.206]

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

Как отмечалось в гл. 13, выбор заголовков, которые включаются в документ, и их последовательность не произвольны. Представленные в этой главе форматы составлены в соответствии с принципом проектирования сверху вниз, т. е. наиболее важные вопросы помещаются первыми незначительные исключения составляют те случаи, где обеспечение удобства чтения текста важнее сохранения реальной схемы декомпозиции проекта. В представленных форматах используется способ нумерации, позволяющий реализовать вложенную структуру документов, удобную с точки зрения возможности дополнения и исключения отдельных разделов. Например, в гл. 13 в табл. 13.2 приведено оглавление подобной структуры для соглашения о требованиях (СТ), внешней спецификации (ВшС), внутренней спецификации (ВтС) и спецификации сопровождения (СС). Элементы каждого такого документа обозначаются следующим образом 3 — заголовок, Об— общая формулировка, Ч — частичная формулировка, Ок — окончательная формулировка. Преобразование 3->-Об->-Ч->Ок, направленное в одну сторону, осуществляется в процессе принятия проектных решений.  [c.268]

Для всех разделов и подразделов следует приводить схему иерархии, которая является своего рода указателем подразделов. Удобна, например, древовидная или вложенная структура, подобная представленной ниже. Каждый подраздел п должен посвящаться какой-либо одной функциональной возможности. Функции целесообразно организовывать в модули, соответствующие физическим модулям в ВтС, чтобы процесс декомпозиции проекта в ВтС мог быть продолжен в разд. 15.2. Однако в процессе декомпозиции не должны упускаться из виду требования организации ВшС в соответствии с логическими функциями. При этом после составления ВтС нетрудно будет преобразовать логические модули в физические. Пример показан на рис. 15.1.  [c.273]

При составлении СОР вы можете столкнуться с тем, что достижения должны быть определены подробнее. В процессе декомпозиции проекта вы можете обнаружить новые достижения, которые пропустили в процессе планирования сферы действия проекта. Эти дополнения должны быть внесены в документ, определяющий сферу действий проекта. Корректировка сферы действия проекта является результатом процесса определения сферы действия, который и позволяет вам осуществить это.  [c.168]

Процесс определения сферы действия связан с декомпозицией проекта и созданием СОР. Достижения разбиваются на управляемые части работы, которые могут быть разделены в дальнейшем на действия.  [c.171]

Структура декомпозиции проекта (PBS) — в общем случае то же, что и правильно составленная WBS. Термин PBS широко применяется там, где термин WBS ошибочно используется для обозначения списка материалов (ВОМ).  [c.62]

На основе исходной информации о проекте проводится последовательная декомпозиция (разбиение, деление на категории, классификация) по заданным основаниям (признакам, критериям) работ проекта. Для наглядности и простоты использования декомпозиции каждому элементу присваивается уникальный идентификатор, соответствующий уровню с использованием разделителей типа табуляции, знаков препинания и т. д.  [c.370]

Структурная схема комплекса является описанием структуры, необходимой для выполнения декомпозиции. Состав и порядок реализации элементных проектов- определяется формой структурной схемы комплексного инвестиционного проекта, создаваемой для  [c.370]

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

Декомпозиция является необходимым инструментом управления для менеджера проекта, так как позволяет определить работы, обеспечивающие достижение частных целей элементных проектов проверить, все ли цели будут достигнуты в результате реализации проекта создать удобную, соответствующую целям проекта структуру отчетности определить ответственность за достижение целей проекта между исполнителями элементных проектов, гарантировать, что все работы по проектам имеют ответственных и не выпадут из поля зрения обеспечить понимание общих целей и задач по проекту.  [c.371]

Для инновационных продуктов поиск близких или полных аналогов (законченных продуктов с определенным набором свойств) может быть затруднителен. В таком случае необходимо найти информацию о нескольких аналогах, свойства которых охватывают отдельные группы характеристик инновационного продукта, и также сравнить по вышеописанной методике (усреднив также цену) предложения всех выявленных аналогов. Если не выявлены товары — конкуренты, имеющие полностью или частично аналогичные потребительские характеристики, то возможно сравнить продукты по принципу функционального замещения, иными словами ведется поиск товаров с подобной функциональной потребительской применимостью. Ограниченность приведенной методики функциональной декомпозиции заключается в невозможности ее использования в случае, если не найдено даже функциональных аналогов. В этом случае речь может идти или об отсутствии маркетинговой проработки рынка, или о прорывном инновационном результате, для оценки инвестиционной привлекательности которого необходима экспертная оценка проекта как целого с точки зрения соответствия его результатов уровню научно-технического прогресса и сформированное потребности рынка. В этом случае для предварительных оценок можно пользоваться методикой сравнения с идеальным продуктом (табл. 4.2).  [c.26]

При разработке проекта используются методы структурной декомпозиции  [c.20]

Декомпозиция целей — декомпозиция этапов проекта на более мелкие  [c.25]

Структура декомпозиции работ проекта — способ описания целей и задач  [c.182]

Управление проектами базируется на системном подходе к процессу управления, что дает возможность декомпозиции и структуризации управления реализацией проекта любой сложности при его рассмотрении. Системно-ориентированная модель управления реализацией стратегических изменений в деятельности предприятия позволяет представить его как процесс реализации определенных связей между всеми элементами проекта, обеспечивающими достижение поставленных целей.  [c.291]

Стадия детального проектирования ИС связана с декомпозицией крупноблочной структуры системы на компоненты и выбором готовых компонентов (прикладных программ повторного использования, покупных программных и технических средств среды). При выборе и заказе готовых компонентов применяются функциональные профили ИС, полученные на предыдущих стадиях проекта. Применение функциональных профилей в этих случаях заключается в том, чтобы предъявить к используемым компонентам требования их соответствия стандартам применяемого профиля и формировать требования к тестам, проверяющим это соответствие.  [c.81]

Для этого выполняют декомпозицию целей проекта. Декомпозиция целей проекта состоит в разделении основных результатов проекта на более детальные компоненты до тех пор, пока эта детализация не окажется достаточной для целей управления проектом.  [c.212]

Выполняется декомпозиция целей проекта в виде упомянутой иерархической структуры работ. Элементы ИСР нижнего уровня рассматривают как пакеты работ. В общем случае можно рекомендовать наиболее характерную последовательность декомпозиции целей проекта  [c.212]

Структура разбиения (декомпозиции) работ (WBS — Work Breakdown Stru ture) — иерархическая структура последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня, пакеты детальных работ. СРР является базовым средством для создания системы управления проектом, так как позволяет решать проблемы организации работ, распределения ответственности, оценки стоимости, создания системы отчетности, эффективно поддерживать процедуры сбора информации о выполнении работ и отображать результаты в информационной управленческой системе для обобщения графиков работ, стоимости, ресурсов и дат завершения.  [c.355]

Некоторые формы иерархической декомпозиции, с которыми мы встретимся, представляют собой нисходящее управление (гл. 5), декомпозицию планов (гл. 6), декомпозицию проекта (гл. 7) и структурирование планов выпуска и спецификаций изделий (частично гл. 13 и разд. 15.1—15.3). Вероятно, многие знакомы с такими видами формальной иерархической декомпозиции, как поэтапная обработка [11], уровни абстракции [12], иерархия документации [13], нисходящее программирование [14], модульная декомпозиция [15], композиционное [16] и структурное [17] проектирование. Александер [18] предлагает весьма интересное представление декомпозиции. В небольшой, но очень полезной книге он проводит философское обсуждение процессов анализа и синтеза конструкций, за которым следует математический метод разложения множества ограничений на подмножества, приводящий к минимизации их взаимодействия. Его работы и работы Бёма [19], Хоара [20], Милза [21], а также некоторые пока еще не опубликованные работы представляют собой значитёлньый вклад в проектирование программного обеспечения благодаря введению количественной меры оценки этого процесса и средствам доказательства правильности программ.  [c.31]

Основная цель фазы конструирования заключается в выработке и анализе требований к программному изделию. Процесс декомпозиции проекта, начатый при составлении соглашения о требованиях, продолжается путем разбиения спецификаций а два компонента — внутренний и внешний. Внешний проект — это совокупность характеристик программного изделия, которые видит пользователь. Внутренний проект — это совокупность характеристик программного изделия, скрытых от любого пользователя. На первый взгляд это разделение кажется искусственным, однако это не так, поскольку такая классификация характеристик программного изделия дает много преимуществ. Она хорошо согласуется с рядом практических методов программирования, таких, как нисходящее программирование [14], метод утаивания информации (information hiding) [15], композиционное проектирование [16] и структурное проектирование 17]. С точки зрения руководителя несомненным достоинством такой классификации является то, что пользователи могут критически рассматривать те характеристики программного изделия, которые имеют к ним непосредственное отношение, не вдаваясь в критику внутренних характеристик изделия. Другими словами, можно во внешних спецификациях описать, что делает программное изделие, а во внутренних спецификациях указать, каким образом оно должно быть сконструировано. Внеш-  [c.105]

Структура проекта, создаваемая на основе декомпозиции, позволяет оптимизировать процедуры сбора и обработки информации о ходе выполнения работ по проекту в соответствии с уровнями управления, видами элементных проектов, обобщать информацию по графикам потоков денежных средств и производственных ресурсов. ASE-технологии повышают эффективность проведения структурного анализа при комплексном инвестиционном проектировании.  [c.371]

Решения подобных проблем выходят за рамки экономической целесообразности и требуют умения воздействовать на общественное мнение или учитывать политические издержки осуществления проектов, разрабатываемых муниципальными организациями. Их успешное решение во многом определяется опытом руководства, интуицией и гибким реагированием на изменения общественного мнения. Задача же аналитических методов, подобных АЗВ, состоит в том, чтобы представить сложную проблему, требующую стратегического выбора, в виде совокупности субпроблем (декомпозиция), одни из которых имеют достаточно простое аналитическое решение, другие требуют развития системы взаимодействия муниципальной организации с внешней средой.  [c.289]

Декомпозиция работ [Work Breakdown Stru ture (WBS)] — механизм разбиения рабочего процесса (в общем случае связанного с определенным проектом) на меньшие элементы, которые могут использоваться для назначения ресурсов, бюджета, расписаний и т.д. WBS обеспечивает базис управления проектом.  [c.310]

В справочной системе локализованных версий Proje t 2002 используется термин «структурная декомпозиция работ», что позволило образовать аббревиатуру СДР. Но значительная часть отечественных специалистов по управлению проектами вместо него используют термин «иерархическая разбивка работ» или «иерархическая структура работ». Автор не считает возможным нарушить эту традицию.  [c.105]

Функционально-ориентированный дизайн программного обеспечения Вопросы с несколькими вариантами ответов

Этот набор основных вопросов и ответов по разработке программного обеспечения посвящен «Функционально-ориентированному проектированию программного обеспечения».

1. Выберите вариант, который не определяет функционально-ориентированный дизайн программного обеспечения.
a) Он состоит из определений модулей
b) Модули представляют абстракцию данных
c) Модули поддерживают функциональную абстракцию
d) Ни один из упомянутых
View Answer

Ответ:b
Объяснение: Вариант b определяет объектно-ориентированный дизайн.

2. Что из следующего является дополнительным подходом к функционально-ориентированному подходу?
a) Объектно-ориентированный анализ
b) Объектно-ориентированный дизайн
c) Структурированный подход
d) Объектно-ориентированный анализ и проектирование
Просмотреть Ответ

Ответ:d
Объяснение: Нет.

3. Методы функционально-ориентированного проектирования начинаются с функциональных требований, указанных в
a) SDD
b) SRS
c) Все упомянутые
d) Ни один из упомянутых
Просмотреть Ответ

Ответ:b
Объяснение: Нет.

4. Структурный анализ основан на принципах
a) Декомпозиция сверху вниз
b) Принцип «разделяй и властвуй»
c) Графическое представление результатов с использованием DFD
d) Все упомянутые
Просмотреть ответ

Ответ:d
Объяснение: Нет.

5. Что из следующего верно в отношении функций?
а) Функция, такая как «книга поиска», представлена ​​кружком
б) Функции представляют некоторую деятельность
в) Символ функции известен как символ процесса или кружок в DFD
г) Все упомянутые
Просмотреть ответ

Ответ:d
Объяснение: Все варианты верны в отношении функционально-ориентированного проектирования программного обеспечения.

6. Что из нижеперечисленного не является использованием инструмента CASE?
a) Поддерживает структурный анализ и проектирование (SA/SD)
b) Поддерживает словарь данных
c) Проверяет сбалансированность DFD
d) Соответствует доступной системе
Просмотреть ответ

Ответ:d
Объяснение: Требуется много времени, чтобы установить систему, чтобы соответствовать имеющейся системе.

7. Какая нотация DFD представлена ​​прямоугольником?
a) Преобразование
b) Хранилище данных
c) Функция
d) Ни один из упомянутых
Просмотр ответа

Ответ:b
Объяснение: Нет.

8. Структурная декомпозиция связана с вызовами функций.
a) Верно
b) Неверно
Просмотреть ответ

Ответ:a
Объяснение: Структурная декомпозиция связана с разработкой модели проекта, которая показывает динамическую структуру.

9. Функционально-ориентированный дизайн фокусируется на объектах системы, а не на действиях по обработке данных.
a) Верно
b) Ложно
Просмотреть ответ

Ответ:b
Объяснение: Это объектно-ориентированный дизайн, который фокусируется на объектах.

10. В DFD взаимодействие пользователя с системой обозначается
a) Круг
b) Стрелка
c) Прямоугольник
d) Треугольник
Просмотреть Ответ

Ответ:a
Объяснение: Нет.

Sanfoundry Global Education & Learning Series – Software Engineering.

Вот список лучших книг по программной инженерии.

Следующие шаги:
  • Получите бесплатный сертификат о заслугах в области разработки программного обеспечения
  • Примите участие в конкурсе по сертификации программной инженерии
  • Станьте лучшим специалистом в области разработки программного обеспечения
  • Пройдите тесты по разработке программного обеспечения
  • Практические тесты по главам: глава 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
  • Пробные тесты по главам: глава 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

Функциональная декомпозиция – обзор

5.1 Согласованная функциональная основа

Более поздний исследовательский проект, основанный на фундаментальной работе Пала и Бейтца, представляет собой проект Согласованная функциональная основа . Эта согласованная функциональная основа ( RFB , ϕотныне) является результатом усилий по установлению стандартной таксономии основных технических функций (см., например, [Hirtz et al. , 2002]) путем согласования двух предыдущих таксономий: таксономия NIST (см. [Szykman, et al. , 1999]) и более старые версии Functional Basis (разработанные в [Little et al., 1997; Камень и др. , 1998 г.; МакАдамс и др. , 1999 г.; Камень и др. , 1999 г.; Камень и дерево, 2000]). Каждая из этих таксономий является результатом эмпирического обобщения технических условий.

RFB анализирует понятие функциональной декомпозиции на фоне таксономии функций, основанной на таксономии потоков. RFB изменяет значение термина «поток», поскольку здесь «поток» не означает «процесс течения» (например,, удаление мусора), а «вещь, которая течет» (например, мусор). 34 Точнее говоря, в некоторых работах, например в [Stone and Wood, 2000], этот термин употребляется в обоих значениях, но таксономия потоков RFB основана на последнем смысле. Этот сдвиг в значении, безусловно, оправдан, поскольку трудно понять, как можно провести различие между процессом течения и функцией, учитывая концепцию Паля и Бейтца. Вся таксономия потоков RFB представлена ​​в таблице 2.

Таблица 2.Таксономия потоков RFB [Hirtz et al. , 2002]

9
Средний поток Третичный поток
GAS
GAS
Liquid
Solid объект
Композит
Liquid-Liquid
Сплошное твердое вещество
Solid-Liquid
жидкий газ
Solid-Gas
2000163
Состояние
Onfactory
Tactile
Вкус
Зрение
CONTROL Analog
Chemical
Electrical
Electrical
Электромагнитный
Электромагнитный Optical
Магнит
60166
пневматичны
Радиоактивные / ядерные
Thermal

RFB также содержит трехуровневую классификацию так называемых основных функций.Каждый тип функции сопровождается определением (на естественном языке), примером и набором синонимичных имен. Основные функции разделены на первом уровне на восемь основных типов. Затем некоторые первичные базовые функции делятся на типы вторичных основных функций, а некоторые из этих вторичных основных функций, в свою очередь, делятся на типы третичных основных функций. Вся таксономия представлена ​​в таблице 3.

Таблица 3. Таксономия функций RFB [Hirtz et al. , 2002]

1 Sense
Основные функции Средние функции Третичные функции
филиал
Extract
Удалить
Распределение
канал
канал Import
Экспорт
Трансфер
Руководство
ROTATE
ROTATE
Разрешить степень (ы) свободы
Connect Connect Пара Присоединиться
REGULY Увеличение
Уменьшение
Изменить Увеличение
STOP
STOP
Inhibit
Конвертировать Конвертировать
Provision Магазин содержать
99
Supply
Укажите Track
Дисплей
Процесс
Подставка Стабилизация
Secure
Position

Конечно, РФБ Тамономия основных функций не является моделью функционального разложения.Например, тот факт, что Разделить и Извлечь являются подтипами Разделить , не означает, что первые являются подфункциями последнего. Более того, базовые функции не являются функциями в том смысле, в каком таковыми являются общие функции, поскольку общие функции представляют собой (сложные) модификации конкретных входных потоков в конкретные выходные потоки, тогда как базовые функции являются модификациями, обобщенными для подвергаемых воздействию потоков. Следовательно, основные подфункции в RFB должны быть отождествлены с базовыми функциями, работающими с конкретными первичными, вторичными и третичными потоками.

В RFB функциональная декомпозиция представляет собой концептуальную структуру, состоящую из декомпозируемой общей функции, ее подфункций, на которые декомпозируется общая функция, потоков, которые модифицируются подфункциями, и сети, которая связывает эти модификации в упорядоченном виде. способ.

Общая функция, подлежащая декомпозиции, определяется в терминах изменяемых ею потоков, которые берутся из таксономии потоков RFB. Каждая из ее подфункций определяется как в терминах потоков, которые модифицирует соответствующая подфункция, так и в терминах ее типа модификации, который берется из таксономии базовых функций RFB.Например, общая функция отвертки, состоящая в закручивании/ослаблении винтов, определяется с помощью следующих десяти входных потоков и девяти выходных потоков (см. также рис. 3).

Рисунок 3. RFB-моделирование общей функции отвертки [Stone and Wood, 2000, Fig. 2]

потоки энергии: электричество, человеческая сила, относительное вращение и вес ;

потоки материалов: ручные, биты и шурупы ;

потоки сигналов: направление, сигнал включения/выключения и сигнал ручного использования ;

выходные потоки для функции затяжка/ослабление винтов :

потоки энергии: крутящий момент и вес, человеческая сила, тепло, тепло, 13;

потоки материалов: ручные, биты и шурупы ;

потоки сигналов: неплотность/герметичность .

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

входные потоки для подфункции преобразования электроэнергии в крутящий момент :

потоки энергии: электричество ;

материальные потоки: нет;

потоки сигналов: нет.

выходные потоки для подфункции преобразования электроэнергии в крутящий момент :

потоки энергии: тепло, шум и крутящий момент;

материальные потоки: нет;

потоки сигналов: нет.

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

В RFB предполагается, что каждая подфункция общей функции, которая должна выполняться технической системой S , реализуется компонентом S; однако связь между подфункциями и компонентами является отношением «многие ко многим», т. е. одна подфункция может быть реализована несколькими компонентами, а один компонент может реализовать более одной подфункции.

Понятие функциональной декомпозиции, разработанное в RFB, играет важную роль в так называемом генераторе понятий, который представляет собой вычислительный инструмент на базе Интернета для улучшения концептуального дизайна. 35 Генератор концепций должен предоставить дизайнеру ряд различных решений его или ее проектной задачи на основе ранее разработанных (и сохраненных) высококачественных проектов. Одним из входных данных, которые должны быть предоставлены для этого инструмента, является функциональная цепочка для вновь разрабатываемого продукта. Выходные решения описывают проектное решение в терминах технических систем, описания которых загружаются в базу знаний генератора понятий. Функциональная декомпозиция связывает общую функцию, установленную генератором, с концептуальными компонентами, составляющими общее описание продукта, которое рассматривается здесь как решение исходной задачи проектирования [Strawbridge et al., 2002 г.; Брайант и др. , 2004].

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

В нашей терминологии общая функция функционального разложения RFB Decomp (Φ, Org 1 , ϕ 2 , …, ϕ n ) ) но может быть любой функцией Φ 07 подфункции ϕ 1 , ϕ 2 , …, ϕ n должны быть отождествлены с базовыми функциями RFB из таблицы 3, действующими на конкретных первичных, вторичных и третичных потоках RFB из таблицы 2.Сеть потоков между подфункциями φ 1 , φ 2 , …, φ N Определяет свою организацию ORG 1 , φ 2 , …, φ N ).

В РФБ общие функции φ и подфункции φ 1 , Φ 2 , …, φ N N в функциональных разложениях Decomp (φ, ORG 1 , φ 2 , …, Φ N N )) Может быть описание Системы S и S и S , S 2 , …, S N , которые являются энуриентами и пердудантами, но, как и в методологии Пала и Бейтца, снова делаются дополнительные предположения о том, что функции подчиняются физическим законам сохранения для потоков и что подфункции быть взятым из набора основных функций.Еще одним дополнительным предположением, по-видимому, является то, что функциональные упорядочения ϕ i → ϕ j составляют организации Org 1 , подфункции всегда асимметричны: потоки между двумя подфункциями в функциональной декомпозиции, как показано на рисунке 4, всегда идут в одном направлении. Преимущество философских исследований функциональных описаний для инженерии может снова заключаться в том, чтобы сделать эти предположения явными и подвергнуть их сомнению.Требование о том, что функции всегда должны быть декомпозированы на базовые функции RFB, работающие с конкретными потоками RFB, снова создает противоречие между целью функциональной декомпозиции для облегчения проектирования и облегчения коммуникации. Рассмотрим, например, базовую функцию преобразования акустической энергии в электрическую энергию . Идентификация этой базовой функции в декомпозиции общей функции может быть полезна для общего понимания этой общей функции, но не поможет разработчикам легко найти соответствующее проектное решение.Требование, чтобы подфункции были упорядочены только в одном направлении, может, в свою очередь, быть полезным в инженерии для управления потоками материалов, энергии и сигналов, но также может оказаться ненужным ограничением для декомпозиции функций.

(PDF) Структурная и поведенческая декомпозиция в объектно-ориентированных моделях

В SDL определение типов (классов) и использование

экземпляров или наборов экземпляров типов в структурной декомпозиции строго разделены, тогда как UML выражает декомпозиция

как отношение агрегации/композиции на уровне класса

.Композиция SDL не позволяет объектам-частям

мигрировать в другие составные объекты. Что касается поведенческой

декомпозиции, все три метода основаны на картах состояний

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

, но может быть найдено в [15].

Хотя семантика концепций декомпозиции в

SDL-2000 может быть полностью объяснена с помощью преобразования в базовый SDL

,

прямая семантическая основа является предпочтительным решением.Текущая работа над новой формальной семантикой для

SDL [13], основанной на концепции ASM (Abstract State

Machine), обеспечивает такую ​​прямую семантическую основу.

6. Заключение

В большинстве объектно-ориентированных языков структурная и поведенческая декомпозиция определяются как отдельные понятия без

или с несколькими комбинациями или отношениями друг к другу. Концепции для

структурной декомпозиции, например. агрегаты и состав

.Концепции поведенческой декомпозиции, например. составные состояния

для заданного поведения конечного автомата и

процедуры как часть переходов. В то время как агрегация и композиция

позиции задаются специальными ассоциациями между классами, конечные автоматы

задаются для отдельных классов. Влияние структурной декомпозиции на поведение и поведенческой декомпозиции на структуру часто определяется довольно расплывчато.

Основная сила SDL заключается в структурном разложении.

Объектно-ориентированные понятия как классы (типы в SDL) и

наследования были введены в язык в 1992 году. Было

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

(с формальной семантикой) комбинированные механизмы, такие как объекты

, с конечными автоматами и внутренней структурой связанных

объектов, составные состояния с четко определенными интерфейсами, мех. —

анизмы для наследования такого комбинированного конечного автомата и

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

структур, а также механизмы для связи и

обмена данными между содержащимися элементами. Сочетание

новой концепции агента с концепцией интерфейсов делает

SDL хорошо подходящим для проектирования и разработки приложений в контексте распределенных систем и промежуточного программного обеспечения

платформ (например, CORBA)

R

ССЫЛКИ

[1] МСЭ-Т: Рек.Z.100 — SDL — Спецификация и язык описания МСЭ-Т

, МСЭ-Т, Женева, 1996 г.

[2] МСЭ-Т: Рек. Z.100 — SDL-2000 — Спецификация и описание МСЭ-Т

Язык, МСЭ-Т, Рек. Z.100, Женева, ноябрь 1999 г.

[3] Рек. Х.901 | ISO/IEC 10746-1: Открытая распределенная обработка —

Эталонная модель, часть 1, ITU-T ‘95

[4] ITU-T: Рек. Z.109 — SDL в сочетании с UML, ITU-T, Предложение проекта стандарта

, Женева, 1999 г.

[5] OMG: Спецификация унифицированного языка моделирования OMG (UML

V1.3), OMG, 1999.

[6] B. Selic, G. Gullekson, PT Ward: Real-Time Object-Oriented Modeling

(ROOM), Wiley&Sons, 1994.

[7] O.Lehrmann Madsen, B. Møller-Pedersen, K. Nygaard: Object Oriented

Programming in the BETA Programming Language, Addison-Wesley,

1993.

[8] B. Møller-Pedersen: SDL/UML Alignment: Composite States, Ericsson

AS, 1998

[9] Б. Меллер-Педерсен, Э. Хольц: Генерация динамических блоков и совместное использование данных

между процессами, ITU-T Temp.Документ TD-25E, Женева, 1999 г.

[10]E. Holz: Active Entities, Временный документ ITU-T, TDT-620, Tou-

louse, 1999.

[11]E. Holz: Применение UML в процессе проектирования SDL, Proc. of

SAM98, Берлин, 1998 г.

[12]E. Holz: Применение UML в рамках новых телекоммуникационных архитектур, GROOM Workshop on UML, Mannheim, Physica-

Verlag, 1997

[13]U. Глессер, А. Принц: Семантика ASM для SDL, Proc.Девятого форума SDL

(SDL’99), Монреаль, 1999 г.

[14]D. Harel: Executable Object Modeling with Statecharts, in IEEE Computer

, Vol.30, No. 7, pp 31-42, 1997.

[15]B. Мёллер-Педерсен, Д. Ногва: Масштабируемый и объектно-ориентированный SDL

State(chart)s. FORTE/PSTV’99, Пекин.

Таблица 1. Сравнение концепций разложения

SDL UML Rooms

структурное разложение

концепция структурное разложение

Concept

Concept

содержала

(и, возможно,

вложенных) агентов

агрегация /

состав

содержал

(но не

вложенных)

Актеры

Производное поведение семантики

Совместные или

Черезвыше

Без семантики

Определенные

Определенные данные

Соблюдение данных YY

*

*.Семантика не определена.

N

N

Доступ к содержанию

Элементы

Управляемые

Ворота / Интерфейс

Без ограничений

Управляемые

Порт / протокол

Миграция содержащихся

Элементы

NYN

Отдельный класс / тип и

определение структуры

yny

определения вложенных классов/типов yn

†. Разрешено Руководством по семантике, но нотация недоступна.

n

Поведенческая декомпозиция y y y

вложенные состояния y y y

параллельные подсостояния y y y

типы/классы состояний y n n

Подробная структурная декомпозиция1 0

Аннотация

Мы представляем алгоритм двумерной подгонки (GALFIT), разработанный для извлечения структурных компонентов из изображений галактик, с упором на точное моделирование световых профилей близких галактик с пространственным разрешением, наблюдаемых с помощью космического телескопа Хаббла.Наш алгоритм улучшает предыдущие методы в двух областях: он может одновременно подбирать галактику с произвольным количеством компонентов и оптимизировать скорость вычислений, что подходит для работы с большими изображениями галактик. Мы используем двумерные модели, такие как «закон Нукера», профиль Серсика (де Вокулёра), экспоненциальный диск и функции Гаусса или Моффата. Азимутальные формы представляют собой обобщенные эллипсы, которые могут соответствовать дискообразным и прямоугольным компонентам. Некоторые потенциальные приложения нашей программы включают: стандартное моделирование глобальных профилей галактик; извлечение баров, звездных дисков, двойных ядер и компактных ядерных источников; и измерение абсолютного поглощения пыли или колебаний поверхностной яркости после удаления модели галактики.При детальном рассмотрении мы обнаруживаем, что даже просто выглядящие галактики обычно требуют точного моделирования как минимум трех компонентов, а не одного или двух, которые используются чаще. Многие галактики со сложными изофотами, изменениями эллиптичности и поворотами позиционного угла можно точно смоделировать в двух измерениях. Мы иллюстрируем это с помощью 11 тематических исследований, которые включают правильные спиральные галактики и галактики с перемычкой, линзообразные галактики с высокой дискообразностью и эллиптические галактики, демонстрирующие различные уровни сложности.Полезным расширением этого алгоритма является точное извлечение ядерных точечных источников в галактиках. Мы сравниваем двухмерные и одномерные методы извлечения на смоделированных изображениях галактик, имеющих ядерные наклоны с разной степенью остроты, а затем мы иллюстрируем применение программы к нескольким примерам близких галактик со слабыми ядрами. На основе наблюдений с помощью космического телескопа Хаббл НАСА/ЕКА, полученных в Научном институте космического телескопа, которым управляет Ассоциация университетов по исследованиям в области астрономии (AURA), Inc., по контракту НАСА NAS 5-26555.

Нормально-координатное структурное разложение гемоглобина с искажениями гемоглобина в различных четвертичных состояниях и связанными с аллостерическими эффекторами

Искажения гемов альфа1, альфа2, бета1 и бета2 человеческого гемоглобина (HbA) в различных четвертичных состояниях и под влиянием присутствия аллостерических эффекторов были исследованы путем применения моделей CHARMM с минимальной энергией к анализу нормального координатного структурного разложения (NSD). .NSD применяли к отдельным гемам, извлеченным из моделей состояний R, T и R2 HbA, а также к HbA, связанному с DPG и IHP. В целом, результаты NSD указывают на характерные искажения не только для гемов различных четвертичных состояний HbA, но также и для гемов моделей HbA, связанных с аллостерическими эффекторами. Сравнивая искажения неэквивалентных альфа- и бета-гемов в T-состоянии HbA, мы показываем хорошую корреляцию между NSD и экспериментально наблюдаемыми низкочастотными модами nu52 (Eg) и gamma7 (A2u), описанными в литературе для альфа- и бета-гемов HbA, в то время как отмечая существенные различия между этими типами для искажений B2u и B1u.Для гемов R2 NSD дает искажения гема, которые более сопоставимы с искажениями R-состояния, особенно по величине. Однако гемы R2 не проявляют неравноценности искажений альфа- и бета-гема, что может способствовать пониманию функциональной важности этого состояния. Что касается искажений гема в Т-состоянии, результаты NSD для гемов, связанных с эффекторами, показывают, что третичные изменения, вызванные в Т-состоянии HbA в результате связывания DPG и IHP, резко влияют на искажения гема.В альфа-гемах, извлеченных из модели HbA-DPG, наиболее примечательными являются повышенные искажения wav(x) и wav(y) и усиление деформаций ruf и dom. В бета-гемах искажение wav(y) больше всего страдает при увеличении sad. Результаты NSD также отличаются для гемов модели HbA-IHP тем, что деформации бета-сада и ruf более выражены с увеличением куполообразности в альфа-гемах. Наши результаты описывают влияние тонких изменений, вызванных белком, на неплоскостность гемов HbA, которые могут играть роль в регуляции их сродства к кислороду.

Изменчивость включена одновременное разложение моделей при структурных и процедурных взглядах — исследования @ WUR

@inbook {0CBC30396D164C18823659CCB33C3709,

Название = «Изменчивость включена одновременное разложение моделей при структурных и процедурных представлениях»,

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

автор = «{Чагри Кая}, Мухаммед и Сельма Сулоглу и Гюль Токдемир и Бедир Текинердоган и Догру, {Али Х.}»,

год = «2019»,

месяц = ​​январь,

день = «15»,

doi = «10.1201/97804267-5″,

language = «English»,

isbn = «9780815348054»,

editor = «I. Мистрик и М. Галстер и Б.Р. Максим»,

booktitle = «Разработка программного обеспечения для систем с высокой вариабельностью»,

издатель = «Taylor & Francis»,

}

О применении структурной декомпозиции для модели процесса…

При применении из структурной декомпозиции для < strong>Процесс Модель Абстракция Артем Поливяный, Сергей Смирнов и Матиас Веске Бизнес Процесс Группа технологий Институт Хассо Платтнера при Университете оф Потсдам D-14482 Потсдам, Германия {Арт.Поливяный,Сергей Смирнов,Матиас.Веске}@hpi.uni-potsdam.de Аннотация: Реальные модели бизнес-процессов могут состоять из сотен элементов и иметь сложную структуру. Хотя есть задачи, в которых такие модели ценны и ценятся, в целом сложность отрицательно влияет на понимание и анализ модели. Таким образом, необходимы средства для управления сложностью моделей процессов.Единыйподход — это абстрагирование моделей бизнес-процессов — создание модели процесса, которая сохраняет основные черты моделей бизнес-процессов. первоначальная сложная модель процесса, но не учитывающая незначительные детали. В этой статье мы изучаем структурные аспекты абстракции модели процесса и представляем подход к абстракции, основанный на деревьях структуры процессов (PST). Разработанный подход гарантирует, что абстрактная модель процесса сохраняет ограничения порядка исходной модели.Он превосходит подходы к абстракции моделей процессов на основе шаблонов, позволяя работать с графоструктурными моделями процессов с произвольной структурой. Мы также предоставляем оценку предложенного подхода. 1 Введение Управление бизнес-процессами — важный подход к представлению и улучшению методов работы компаний в динамичных и конкурентных условиях [HC94]. В большинстве случаев одной модели для одного бизнес-процесса недостаточно, поскольку разные типы анализа бизнес-процессов требуют разных точек зрения для одного процесса.Некоторые задачи анализа подразумевают исчерпывающее описание процесса, в то время как для других требуется только обзор процесса. Таким образом,например, существует спрос на несколько моделей одного одного и того же процесса, но с разными уровнями абстракции . Между тем, без формальной связи между этими моделями согласованность между ними не может быть гарантирована.

Leave a Reply