Коллектив авторов - Руководство к Своду знаний по управлению проектами (Руководство PMBOK)

• Название: Руководство к Своду знаний по управлению проектами (Руководство PMBOK)
• Автор: Коллектив авторов
• Жанр: Бизнес

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

Является Американским национальным стандартом. В настоящее время в пользовании находятся более 2 миллионов экземпляров Руководства PMBOK.C момента выхода четвертого издания Институт управления проектами получил тысячи ценных разъяснений и рекомендаций по улучшению от мирового сообщества руководителей проектов.

---

5.2.2.8. Прототипы

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

5.2.2.9. Бенчмаркинг

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

5.2.2.10. Контекстные диаграммы

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

5.2.2.11. Анализ документов

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

5.2.3. Сбор требований: выходы

5.2.3.1. Документация по требованиям

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

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

• Бизнес-требования, включая:

– цели организации и проекта для возможности отслеживания;

– бизнес-правила для исполняющей организации;

– руководящие принципы организации.

• Требования заинтересованных сторон, включая:

– воздействие на другие области организации;

– воздействие на другие субъекты внутри или за пределами исполняющей организации;

– требования к коммуникациям и отчетности для заинтересованных сторон.

• Требования к решению, включая:

– функциональные и нефункциональные требования;

– требования соответствия технологиям и стандартам;

– требования к поддержке и обучению;

– требования к качеству;

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

• Требования к проекту, такие как:

– уровни обслуживания, производительности, безопасности, соответствия и т. д.; – критерии приемки.

• Требования к переходу.

• Допущения, зависимости и ограничения в отношении требований.

5.2.3.2. Матрица отслеживания требований

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

Отслеживание включает в себя, среди прочего, отслеживание требований в следующих аспектах:

• бизнес-потребности, а также благоприятные возможности, цели и задачи организации;

• цели проекта;

• содержание проекта/поставляемые результаты ИСР;

• проектирование продукта;

• разработка продукта;

• стратегия и сценарии тестирования;

• детализация от высокоуровневых до более детальных требований.

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

Рис. 5–6. Пример матрицы отслеживания требований

5.3. Определение содержания

Определение содержания – процесс разработки подробного описания проекта и продукта. Ключевая выгода данного процесса состоит в том, что он описывает границы продукта, услуги или результата путем определения того, какие из собранных требований будут включены в содержание проекта и какие исключены из него. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–7. На рис. 5–8 показана диаграмма потоков данных процесса.

Рис. 5–7. Определение содержания: входы, инструменты и методы, а также выходы

Рис. 5–8. Диаграмма потоков данных определения содержания

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

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