Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘проект’

CMMI DEV v1.3 – Мониторинг и Контроль Проекта

Posted by Шамрай Александр на Январь 13, 2011

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 2

Назначение

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

Вступительный комментарий

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

Термин «план проекта» используется в этой процессной области как общий план для контроля проекта.

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

Связанные процессные области

См. процессную область Измерения и Анализ для получения дополнительной информации о спецификации измерений.

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

Перечень специфических целей и практик

  • СЦ 1 Мониторинг Проекта на Основе Плана
    • СП 1.1 Выполняйте Мониторинг Параметров Планирования Проекта
    • СП 1.2 Выполняйте Мониторинг Обязательств по Выполнению
    • СП 1.3 Выполняйте Мониторинг Рисков Проекта
    • СП 1.4 Выполняйте Мониторинг Управления Данными
    • СП 1.5 Выполняйте Мониторинг Участия Заинтересованных Сторон
    • СП 1.6 Проводите Анализ Выполнения
    • СП 1.7 Проводите Анализ Вех
  • СЦ 2 Управление Корректирующими Действиями до Их Закрытия
    • СП 2.1 Анализируйте Проблемы
    • СП 2.2 Принимайте Корректирующие Действия
    • СП 2.3 Управляйте Корректирующими Действиями

Специфические практики по целям

СЦ 1 Мониторинг Проекта на Основе Плана

Реальный прогресс и выполнение проекта контролируется на основе плана проекта.

СП 1.1 Выполняйте Мониторинг Параметров Планирования Проекта

Выполняйте мониторинг фактических значений параметров планирования проекта по отношению к плану проекта.

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

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

Пример рабочих продуктов

1. Отчеты по выполнению проекта

2. Отчеты по значительным отклонениям

3. Финансовые отчеты

Подпрактики

1. Выполняйте мониторинг выполнения на основе рабочего графика.

Мониторинг выполнения обычно включает в себя следующее:

  • Периодические замеры фактического завершения работ и вех
  • Сравнение фактического завершения работ и вех с рабочим графиком плана проекта
  • Выявление существенных отклонений от оценок в графике плана проекта

2. Контролируйте стоимость проекта и выполненных трудозатрат.

Мониторинг трудозатрат и стоимости обычно включает в себя следующее:

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

3. Выполняйте мониторинг атрибутов рабочих продуктов и задач.

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

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

Мониторинг атрибутов рабочих продуктов и задач, как правило, включает следующее:

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

4. Выполняйте мониторинг предусмотренных и используемых ресурсов.

См. процессную область Планирования Проекта для получения дополнительной информации о планировании ресурсов проекта.

Примеры ресурсов:

  • Физические объекты
  • Компьютеры, периферийные устройства и программное обеспечение
  • Сети
  • Обеспечение безопасности
  • Сотрудники проекта
  • Процессы

5. Выполняйте мониторинг знаний и навыков сотрудников проекта.

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

Мониторинг знаний и навыков сотрудников проекта обычно включает в себя следующее:

  • Периодические замеры приобретенных знаний и навыков сотрудниками проекта
  • Сравнение фактической подготовки с тем, что описано в плане проекта
  • Выявление существенных отклонений от оценок плана проекта

6. Документируйте значительные отклонения в параметрах планирования проекта.

 

СП 1.2 Выполняйте Мониторинг Обязательств по Выполнению

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

Пример рабочих продуктов

1. Отчеты по анализу обязательств по выполнению

Подпрактики

1. Регулярно проводите анализ обязательств по выполнению (как внешних, так и внутренних).

2. Определите какие обязательства не были выполнены или какие имеют значительный риск их невыполнения.

3. Документируйте результаты анализа обязательств по выполнению.

 

СП 1.3 Выполняйте мониторинг Рисков Проекта

Выполняйте мониторинг рисков на основе тех, которые указаны в плане проекта.

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

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

Пример рабочих продуктов

1. Отчеты по мониторингу рисков проекта

Подпрактики

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

2. Пересматривайте документацию по рискам при появлении дополнительной информации.

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

3. Сообщайте о состоянии рисков соответствующим заинтересованным лицам.

Примеры состояний риска:

  • Изменение вероятности того, что риск возникнет
  • Изменение приоритета риска

СП 1.4 Выполняйте Мониторинг Управления Данными

Выполняйте мониторинг управления проектными данными в соответствие плану проекта.

См. специфическую практику Планирование Управления Данными процессной области Планирование Проекта для получения дополнительной информации об определении типов данных для управления и как планировать их управление.

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

Пример рабочих продуктов

1. Отчеты по управлению данными

Подпрактики

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

2. Выявляйте и документируйте важные проблемы и их последствия.

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

3. Документируйте результаты анализа мероприятий по управлению данными.

 

СП 1.5 Выполняйте Мониторинг Участия Заинтересованных Сторон

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

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

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

В Agile среде постоянное участие клиентов и потенциальных конечных пользователей в разработке продукта проекта может иметь решающее значение для успеха проекта, поэтому участие клиентов и конечных пользователей в проектной деятельности должно отслеживаться. (См. «CMMI при использовании Agile подходов» в части I.)

Пример рабочих продуктов

1. Отчеты по участию заинтересованных сторон

Подпрактики

1. Периодический анализируйте состояния участия заинтересованных сторон.

2. Выявляйте и документируйте важные проблемы и их последствия.

3. Документируйте результаты анализа состояния участия заинтересованных сторон.

 

СП 1.6 Проводите Анализ Прогресса

Периодически выполняйте анализ прогресса, выполнения и проблем проекта.

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

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

Пример рабочих продуктов

1. Документальные результаты анализа проекта

Подпрактики

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

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

2. Анализируйте результаты собранных и проанализированных замеров для контроля проекта.

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

См. процессную область Измерение и Анализ для получения дополнительной информации о совмещении мероприятий по измерению и анализу и предоставлении результатов измерений.

3. Выявляйте и документируйте важные проблемы и отклонения от плана.

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

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

5. Документируйте результаты анализа.

6. Отслеживайте запросы на изменение и ведите отчеты о проблемах до их закрытия.

 

СП 1.7 Проводите Анализ Вех

Анализируйте достижения и результаты проекта в отдельных вехах проекта.

См. специфическую практику Установка Бюджета и Графика процессной области Планирование проекта для получения дополнительной информации об определении основных вех.

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

Анализ вехи планируется во время планирования проекта и, как правило, это формальные проверки.

Анализ прогресса и анализ вехи не обязательно должны проводиться отдельно. Одним анализом можно провести два. Например, один запланированный анализ может оценить прогресс, проблемы и выполнение через планируемый период времени (или веху) на соответствие ожиданиям плана.

В зависимости от проекта, анализ вех может покрывать фазы «Запуск проекта» и «Закрытие проекта».

Пример рабочих продуктов

1. Документальные результаты анализа вехи

Подпрактики

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

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

2. Анализируйте обязательства по выполнению, планы, состояния и риски проекта.

3. Выявляйте и документируйте важные проблемы и их последствия.

4. Документируйте результаты анализа, действий и решений.

5. Отслеживайте действия до их закрытия.

СЦ 2 Управление Корректирующими Действиями до Их Закрытия

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

СП 2.1 Анализируйте Проблемы

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

Пример рабочих продуктов

1. Список проблем, требующих корректирующих действий

Подпрактики

1. Собирайте проблемы для анализа.

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

Примеры проблем:

  • Проблемы, обнаруженные при проведении технического анализа, проверки и утверждения
  • Значительные отклонения в параметрах планирования проекта от оценок в плане проекта
  • Обязательства по выполнению (внутренние или внешние), которые не были выполнены
  • Существенные изменения в состоянии риска
  • Проблемы доступа к данным, сбора, конфиденциальности или безопасности
  • Проблемы представления и участия заинтересованных сторон
  • Предложения по продукту, инструменту или среды передачи (или другие предложения клиентов или поставщиков), которые не были достигнуты

2. Анализировать проблемы для определения необходимости принятия корректирующих действий.

См. специфическую практику Установка Бюджета и Графика процессной области Планирование Проекта для получения дополнительной информации о критериях для корректирующих действий.

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

 

СП 2.2 Принимайте Корректирующих Действий

Принимайте меры по исправлению выявленных проблем.

Пример рабочих продуктов

1. Планы корректирующих действий

Подпрактики

1. Определяйте и документируйте соответствующие действия, необходимые для решения выявленных проблем.

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

Примеры возможных действий:

  • Изменение Технического Задания
  • Изменение Требований
  • Пересмотр оценок и планов
  • Новое согласование обязательств по выполнению
  • Добавление ресурсов
  • Изменение процессов
  • Пересмотр рисков проекта

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

3. Согласовывайте изменения внутренних и внешних обязательств по выполнению.

 

СП 2.3 Управляйте Корректирующими Действиями

Управляйте корректирующими действиями для их закрытия.

Пример рабочих продуктов

1. Результаты корректирующих действий

Подпрактики

1. Выполняйте мониторинг корректирующих действий для их завершения.

2. Анализируйте результаты корректирующих действий для определения их эффективности.

3. Определяйте и документируйте соответствующие действия для исправления отклонений от запланированных результатов по выполнению корректирующих действий.

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

Реклама

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

CMMI DEV v1.3 – Планирование проекта

Posted by Шамрай Александр на Январь 11, 2011

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 2

Назначение

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

Вступительный комментарий

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

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

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

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

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

Для линейки продукта, существует различный набор мероприятий, которые выиграют от использования практик этой процессной области. Эти мероприятия включают в себя создание и поддержку основных активов, разработку продуктов с использованием основных активов и организацию общих трудозатрат для поддержки и координации операций взаимосвязанных рабочих групп и их деятельности. В Agile среде инкрементальная разработка включает в себя планирование, мониторинг, контроль и перепланировке чаще, чем в традиционной разработке. Хотя план на высоком уровне для всего проекта или трудозатрат обычно создается, команды оценивают, планируют и обеспечивают фактическое выполнение инкремента или итерации все время. Обычно команды не прогнозируют то, что вне проекта или итерации, за исключением прогнозирования рисков, основных событий и крупномасштабных воздействий и ограничений. Оценки отражают итерационные и командные факторы, которые влияют на время, трудозатраты, ресурсы и риски для выполнения итерации. Команда планирует, отслеживает и корректирует планы во время выполнения каждой итерации так часто, на сколько это требуется (например, ежедневно). Обязательства по выполнению в плане обеспечиваются, когда задачи назначены и приняты во время планирования итерации, пользовательские истории разработаны или оценены и итерации составлены из задач, содержащихся в журнале работ. (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессные области

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

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

См. процессную область Измерения и Анализ для получения дополнительной информации о спецификации измерений.

См. процессную область Управление Требованиями для получения дополнительной информации о управлении требованиями.

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

Перечень специфических целей и практик

  • СЦ 1 Сформировать Оценки
    • СП 1.1 Оценивайте Масштаб Проекта
    • СП 1.2 Формируйте Оценки Атрибутов Рабочих Продуктов и Задач
    • СП 1.3 Определяйте Фазы Жизненного Цикла Проекта
    • СП 1.4 Оценивайте Трудозатраты и Стоимость
  • СЦ 2 Разработать Плана Проекта
    • СП 2.1 Формируйте Бюджет и График
    • СП 2.2 Определяйте Риски Проекта
    • СП 2.3 Планируйте Управление Данными
    • СП 2.4 Планируйте Ресурсы Проекта
    • СП 2.5 Планируйте Необходимые Знания и Навыки
    • СП 2.6 Планируйте Участие Заинтересованных Сторон
    • СП 2.7 Создайте План Проекта
  • СЦ 3 Получить Обязательства Выполнения по Плану
    • СП 3.1 Пересматривайте Планы, Которые Затрагивают Проект
    • СП 3.2 Согласовывайте Объемы Работы и Ресурсы
    • СП 3.3 Получайте Обязательства Выполнения по Плану

Специфические практики по целям

СЦ 1 Сформировать Оценки

Оценки параметров планирования проекта сформированы и поддерживаются.

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

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

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

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

СП 1.1 Оценивайте Масштаб Проекта

Создавайте структуру декомпозиции работ (СДР) верхнего уровня для оценки масштаба проекта.

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

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

Некоторые проекты используют термин «контрактная СДР», т.е. часть СДР размещается в контракте (возможно, вся СДР). Не все проекты имеют контрактную СДР (например, внутренне финансируемые разработки).

Пример рабочих продуктов

1. Описания задач

2. Описания рабочего пакета

3. СДР

Подпрактики

1. Разрабатывайте СДР.

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

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

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

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

3. Определяйте продукты и компонентов, необходимые для внешней закупки.

См. процессную область Управление Соглашениями с Поставщиками для получения дополнительной информации об управлении приобретением товаров и услуг.

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

СП 1.2 Формируйте Оценки Атрибутов Рабочих Продуктов и Задач

Обеспечивайте и поддерживайте оценивание атрибутов рабочих продуктов и задач.

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

Примеры атрибутов для оценки:

  • Количество и сложность требований
  • Количество и сложность интерфейсов
  • Объем данных
  • Количество функций
  • Функциональные единицы
  • Количество строк кода
  • Количество классов и объектов
  • Количество таблиц базы данных
  • Количество полей в таблицах данных
  • Архитектурные элементы
  • Опыт работы участников проекта
  • Объем кода, который необходим для обеспечения повторного использования вместо новой разработки
  • Командная производительность и сложность
  • Количество страниц
  • Количество входных и выходных элементов
  • Количество технических рисков
  • Количество логических соединений для интеграционных схем
  • Количество частей (например, печатных плат, компонентов, механических частей)
  • Физические ограничения (например, вес, объем)
  • Географическое распределение участников проекта
  • Близость клиентов, конечных пользователей и поставщиков
  • Как сложно или легко договориться с клиентом
  • Качество и «чистота» существующего кода

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

Пример рабочих продуктов

1. Размер и сложность задач и рабочих продуктов

2. Оценка моделей

3. Атрибут оценки

4. Технический подход

Подпрактики

1. Определяйте технический подход к проекту.

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

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

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

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

3. Оценивайте атрибуты рабочих продуктов и задач.

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

  • Поставляемые и непоставляемые рабочие продукты
  • Документы и файлы
  • Операционное и поддерживающее оборудование, микропрограммы и программное обеспечение

СП 1.3 Определяйте Фазы Жизненного Цикла Проекта

Определяйте фазы жизненного цикла проекта, которые обеспечат границы планирования.

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

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

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

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

Пример рабочих продуктов

1. Фазы жизненного цикла проекта

СП 1.4 Оценивайте Трудозатраты и Стоимость

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

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

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

Пример рабочих продуктов

1. Обоснование оценки

2. Оценка трудозатрат проекта

3. Оценка стоимости проекта

Подпрактики

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

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

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

2. Включайте поддержку инфраструктурных потребностей при оценке трудозатрат и стоимости.

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

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

Примеры инфраструктурных ресурсов:

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

3. Оценивайте трудозатраты и стоимость с использованием моделей, исторических данных или комбинации обоих.

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

  • Оценки, выполняемые экспертом или группой экспертов (например, метод Дельфи, Игра по планированию в Экстремальном программировании)
  • Риски, в том числе, в какой степени трудозатраты являются беспрецедентным
  • Критические компетенции и роли, необходимые для выполнения работы
  • Перемещение
  • СДР
  • Выбранная модель жизненного цикла проекта и процессов
  • Оценки стоимости жизненного цикла
  • Уровень квалификации руководителей и сотрудников, необходимых для выполнения работы
  • Необходимые знания, навыки и обучение
  • Прямые трудовые затраты и накладные расходы
  • Соглашение об обслуживании для колл-центров и гарантийных работ
  • Уровень безопасности, необходимый для задач, рабочих продуктов, оборудования, программного обеспечения, персонала и рабочего окружения
  • Необходимые средства (например, офис, помещения для совещаний и рабочие станции)
  • Требования к продукту и компонентам продукта
  • Оценки размера рабочих продуктов, задач и ожидаемых изменений
  • Стоимость внешне приобретенных продуктов
  • Возможности производственных процессов
  • Потребности в инженерных средствах
  • Возможности инструментов, используемых в инженерной среде
  • Технический подход

СЦ 2 Разработать План Проекта

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

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

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

СП 2.1 Формируйте Бюджет и График

Формируйте и поддерживайте бюджет и график проекта.

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

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

Пример рабочих продуктов

1. Рабочие графики проекта

2. Графики зависимостей

3. Бюджет проекта

Подпрактики

1. Определяйте основные вехи.

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

2. Определяйте предположения по графику.

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

3. Определяйте ограничения.

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

4. Определяйте зависимости задачи.

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

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

  • Метод критического пути (CPM)
  • Техники оценки и анализа программы (PERT)
  • Планирование с ограниченными ресурсами
  • Приоритеты клиента
  • Рыночные возможности
  • Значение для конечных пользователей

5. Формируйте и поддерживайте бюджет и график.

Формирование и поддержка бюджета проекта и графика обычно включает в себя следующее:

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

6. Создавайте критерии корректирующих действий.

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

СП 2.2 Определяйте Риски Проекта

Выявляйте и анализируйте риски проекта.

См. специфические практики Мониторинг Рисков Проекта в процессной области Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге рисков.

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

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

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

  • Выявление рисков
  • Анализ рисков для определения воздействия, вероятности возникновения и временных рамок, в которые проблемы могут возникнуть
  • Приоритезация рисков

Пример рабочих продуктов

1. Выявленные риски

2. Воздействия риска и вероятности возникновения

3. Приоритеты рисков

Подпрактики

1. Выявляйте риски.

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

Примеры инструментов для выявления и анализа рисков:

  • Таксономия рисков
  • Оценка рисков
  • Контрольные списки
  • Структурированные интервью
  • Мозговой штурм
  • Процессные, проектные и модели эффективности продукта
  • Стоимостные модели
  • Сетевой анализ
  • Анализ факторов качества

2. Документируйте риски.

3. Анализируйте и согласовывайте с соответствующими заинтересованными сторонами документированные риски на полноту и правильность.

4. Пересматривайте риски по мере необходимости.

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

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

СП 2.3 Планируйте Управление Данными

Планируйте управление данными проекта.

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

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

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

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

Пример рабочих продуктов

1. План управления данными

2. Главный список управляемых данных

3. Описание содержания и формата данных

4. Списки требований к данным для покупателей и поставщиков

5. Конфиденциальные требования

6. Требования к безопасности

7. Процедуры обеспечения безопасности

8. Механизмы для получения, воспроизведение и распространение данных

9. Расписание для сбора данных проекта

10. Список собираемых данных проекта

Подпрактики

1. Устанавливайте требования и процедуры для обеспечения конфиденциальности и безопасности данных.

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

2. Создавайте механизм для архивирования данных и доступа к архивным данным.

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

3. Определяйте данные проекта, которые будут выявляться, собираться и распространяться.

4. Определяйте требования для обеспечения доступа и распределения данных для соответствующих заинтересованных сторон.

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

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

СП 2.4 Планируйте Ресурсы Проекта

Планируйте ресурсы для выполнения проекта.

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

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

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

Пример рабочих продуктов

1. Рабочие пакеты

2. Словарь задач СДР

3. Требования к персоналу в зависимости от размера и масштаба проекта

4. Список критически важных средств и оборудования

5. Диаграммы и описания процессов и последовательности работ

6. Список требований администрирования проекта

7. Отчеты о состоянии

Подпрактики

1. Определяйте требования к процессу.

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

2. Определяйте требования к каналам связи.

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

3. Определяйте требования к персоналу.

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

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

4. Определяйте требования к средствам, оборудованиям и компонентам.

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

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

5. Определяйте другие постоянные потребности в ресурсах.

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

  • Расходные материалы (например, электричество, канцелярские товары)
  • Доступ к интеллектуальной собственности
  • Доступ к перевозке (для людей и оборудования)

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

СП 2.5 Планируйте Необходимые Знания и Навыки

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

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

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

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

Пример рабочих продуктов

1. Перечень необходимых навыков

2. Планы кадрового обеспечения и найма новых сотрудников

3. Базы данных (например, навыки, обучение)

4. Планы тренингов

Подпрактики

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

2. Оценивайте доступные знания и навыки.

3. Выбирайте механизмы для обеспечения необходимых знаний и навыков.

Примеры механизмов:

  • Внутреннее обучение (как организационное, так и проектное)
  • Внешнее обучение
  • Кадровое обеспечение и набор новых сотрудников
  • Внешнее приобретение навыков

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

4. Включайте выбранные механизмы в план проекта.

СП 2.6 Планируйте Участие Заинтересованных Сторон

Планируйте участие выявленных заинтересованных сторон.

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

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

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

  • Список всех соответствующих заинтересованных сторон
  • Обоснование для участия заинтересованных сторон
  • Отношения между заинтересованными сторонами
  • Ресурсы (например, обучение, материалы, время, финансирование), необходимые для обеспечения взаимодействия с заинтересованными лицами
  • График для взаимодействия заинтересованных сторон
  • Роли и обязанности соответствующих заинтересованных лиц по отношению к проекту по фазам жизненного цикла проекта
  • Относительная важность заинтересованных сторон для успешной реализации проекта по фазам жизненного цикла проекта

Реализация этой специфической практики основывается на общедоступной информации или информации общей с предыдущей специфической практикой Планирование Необходимых Знаний и Навыков.

Пример рабочих продуктов

1. План участия заинтересованных сторон

СП 2.7 Создайте Плана Проекта

Создайте и поддерживайте общий план проекта.

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

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

  • Решения по жизненному циклу проекта
  • Задачи проекта
  • Бюджеты и рабочие графики
  • Вехи
  • Управление данными
  • Выявление рисков
  • Требования к ресурсам и квалификации
  • Выявление и взаимодействие с заинтересованными лицами
  • Инфраструктурные решения

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

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

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

  • План разработки программного обеспечения
  • План проекта программного обеспечения
  • План программного обеспечения

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

Примеры планов, которые использовались в Министерстве обороны США:

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

Пример рабочих продуктов

1. Общий план проекта

СЦ 3 Получить Обязательства Выполнения по Плану

Обязательства выполнения по плану проекта сформированы и поддерживаются.

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

СП 3.1 Пересматривайте Планы, Которые Затрагивают Проект

Просматривайте все планы, которые влияют на проект, чтобы понять обязательства по выполнению проекта.

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

Пример рабочих продуктов

1. Отчет по результатам пересмотра планов, которые влияют на проект

СП 3.2 Согласовывайте Объемы Работ и Ресурсов

Выполняйте регулирование плана проекта для согласования доступных и предполагаемых ресурсов.

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

Пример рабочих продуктов

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

2. Пересмотренные бюджеты

3. Пересмотренные рабочие графики

4. Пересмотренный список требований

5. Пересмотренные соглашения с заинтересованными сторонами

СП 3.3 Получите Обязательства Выполнения по Плану

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

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

Пример рабочих продуктов

1. Документированные запросы на подтверждение обязательств по выполнению

2. Документированные обязательства по выполнению

Подпрактики

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

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

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

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

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

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

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

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

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

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

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

 
%d такие блоггеры, как: