Принципы декомпозиции проекта

Да Нет

5. Есть ли зависимость между частью работ внутри пакета работ и другими внешними пакетами? Да Нет

6. Наблюдаются ли существенные перерывы в выполнении работ в рамках пакета? Да Нет

7. Меняются ли требования  к ресурсам в течение времени в рамках выполнения пакета работ? Да Нет

8. Различаются ли исходные условия для работ внутри пакета работ? Да Нет

9. Существуют ли четкие, объективные критерии измерения выполнения для пакета работ? Да Нет

10. Существуют ли специфические риски, связанные с частью пакта работ и требующие дальнейшей детализации пакета для выделения этих рисков? Да Нет

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

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

Взаимосвязь между  риском проекта и WBS

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

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

Взаимосвязь планирования и контроля ресурсов и WBS

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

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

√ Все ли работы запланированы с достаточной степенью детализации, необходимой для формирования и соблюдения обязательств?

√ Существует ли возможность  установления и контроля индивидуальных назначений ресурсов на работы со структурой отчетности, определенной данной WBS?

√ Можно ли определить назначения на работы при постепенном расширении WBS? Будут ли они обоснованы как при разворачивании WBS сверху-вниз, так и при сборе данных снизу-вверх?

√ Будут ли назначения ресурсов на работы согласованы с формальной системой расчета расписания?

√ Как будут распределяться бюджеты?

√ Можно ли будет связать бюджет с предполагаемым увеличением работы?

√ Можно ли измерить увеличение объема работы на приемлемом уровне (т.е. соответствует ли уровень детализации WBS эффективному планированию и

контролю)?

√ Можно ли логически  собрать данные по индивидуальным рабочим заданиям (т.е. можно ли работы, определенные в WBS, сгруппировать логически)?

√ Как будет определяться состояние работ в процессе выполнения проекта?

Разработка WBS

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

Основной процесс разработки WBS состоит из следующих шагов:

1. Определение конечных  результатов проекта – что должно быть произведено (поставлено) для обеспечения успешного завершения проекта.

2. Определение основных пакетов работ, необходимых для получения конечных результатов (продуктов) проекта. Часто такие основные пакеты работ соответствуют целям проекта, но вместе с тем, сами по себе они не являются целями проекта (например, технические требования к разработке

программного обеспечения).

3. Объединение дополнительных уровней детализации в соответствии с внутренней системой управления и единой системой контроля. Такие элементы обычно связаны с четким и раздельным определением отдельных результатов (продуктов) проекта.

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

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

 

 

 

 

 

 

 

Заключение

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список литературы

1. Д. Марка, Р. Макгоуэн. Методология структурного проектирования SADT. М.: Метатехнология, 1993.

2. Черемных С.В. и др. Структурный анализ систем: IDEF- технологии. М.: Финансы и статистика, 2003.

3. Крёнке Д. Теория и практика построения баз данных. СПб: Питер, 2003