Wondershare EdrawMind
Галерея диаграмм связей управление содержанием проекта
- 8
управление содержанием проекта
PMP Глава 5 Управление содержанием проекта. Управление содержанием проекта включает в себя различные процессы, гарантирующие, что проект выполняет и выполняет только всю работу, необходимую для успешного завершения проекта. Проверка содержания — это процесс формальной приемки завершенных результатов проекта.
Отредактировано в 2022-02-24 18:41:57
управление содержанием проекта
- Рекомендовано вам
- Структура
Учебное пособие для менеджера проектов информационных систем (4-е издание) Глава 9_Управление содержанием проекта
- 6
Экзамен по расширенному программному обеспечению. Глава 5. Управление содержанием проекта.
- 5
управление содержанием проекта
определение
Управление содержанием проекта включает в себя процесс обеспечения того, чтобы проект выполнял и выполнял только всю работу, необходимую для успешного завершения проекта. Проверка содержания — это процесс формальной приемки завершенных результатов проекта.
В основном он заключается в определении и контроле того, какие работы следует включать в проект, а какие нет.
Ассортимент продукции
Завершение измеряется в соответствии с требованиями к продукту.
Особенности и функции продукта, услуги или результата.
Объем проекта
Работа, которую необходимо выполнить для предоставления продукта, услуги или результата с указанными функциями и характеристиками. Объем проекта иногда также включает объем продукта.
Завершение объема проекта оценивается по плану управления проектом.
Описание объема прогнозируемого жизненного цикла
Результаты проекта определяются в начале проекта, и любые изменения объема регулируются постепенно.
Проверка содержания происходит по мере создания каждого результата или на этапах поэтапного анализа, тогда как контроль содержания является непрерывным процессом.
Утвержденное описание содержания проекта, иерархическая структура работ (WBS) и соответствующий словарь WBS составляют базовый план содержания проекта. Базовые изменения могут быть внесены только посредством формального процесса контроля изменений.
Адаптивное описание содержания проекта
Общий объем разбивается на ряд требований, которые необходимо реализовать, и работ, которые необходимо выполнить (иногда называемых журналом невыполненных работ по продукту). На каждой итерации повторяются три процесса: сбор требований, определение объема и создание WBS.
В каждой итерации повторяются два процесса: подтверждение объема и контроль объема.
Используйте бэклог, включая требования к продукту и пользовательские истории, чтобы отразить текущие потребности.
Дополнительное объяснение: «Требования» относятся к условиям или возможностям, которыми должны обладать продукты, услуги или результаты в соответствии с конкретными соглашениями или другими обязательными спецификациями. Требования лягут в основу иерархической структуры работ (WBS) и станут основой для планирования затрат, графика, качества и закупок.
Процесс управления требованиями заканчивается закрытием требований, то есть передачей продукта, услуги или результата получателю, чтобы можно было измерять, отслеживать, реализовывать и поддерживать выгоды в долгосрочной перспективе.
Факторы, которые следует учитывать при пошиве
Управление знаниями и требованиями.
Проверка и контроль.
методы разработки.
Стабильность спроса.
Управление.
план
5.1 Управление объемом планирования
определение
Его основная роль заключается в обеспечении руководства и указаний относительно того, как управлять объемом на протяжении всего проекта.
Процесс создания плана управления содержанием для документирования того, как содержание проекта и содержание продукта определяются, проверяются и контролируются.
План управления содержанием — это компонент плана управления проектом или программой, который описывает, как содержание проекта будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться.
входить
Устав проекта
план управления проектом
план управления качеством
То, как политика, методы и стандарты качества организации реализуются в проектах, влияет на способ управления содержанием проекта и продукта.
Описание жизненного цикла товара
Определяет ряд этапов, которые проходит проект от начала до завершения.
метод разработки
Определяет, использует ли проект каскадные, итеративные, адаптивные, гибкие или гибридные методы разработки.
факторы деловой среды
Организационная культура; системы управления персоналом; рыночные условия.
Активы организационного процесса
Инструменты и методы
экспертная оценка
анализ данных
Различные методы оценки и сбора требований, детализации содержания проекта и продукта, создания продуктов, подтверждения содержания и контроля содержания.
Встреча
В число участников могут входить руководитель проекта, спонсор проекта, выбранные члены команды проекта, выбранные заинтересованные стороны, руководители каждого процесса управления содержанием и другой необходимый персонал.
выход
план управления объемом
Определение: План управления содержанием — это компонент плана управления проектом, который описывает, как содержание проекта будет определяться, разрабатываться, отслеживаться, контролироваться и проверяться.
Разработать описание содержания проекта;
Создайте WBS на основе подробного описания содержания проекта.
Определить, как будут утверждаться и поддерживаться базовые показатели содержания;
Официальная приемка завершенных результатов проекта.
*План управления спросом
Определение: Компонент плана управления проектом, который описывает, как требования к проекту и продукту будут анализироваться, документироваться и управляться. Некоторые организации называют это «Программой бизнес-анализа».
Как планировать, отслеживать и составлять отчеты по различным действиям, связанным с требованиями
Действия по управлению конфигурацией, например, как инициируются изменения, как анализируется их влияние и разрешения на утверждение изменений.
процесс приоритезации требований;
Показатели измерения и обоснование их использования;
Структура трассировки, которая отражает, какие атрибуты требований будут включены в матрицу трассировки.
5.2 Сбор требований
Определение: Процесс выявления, документирования и управления потребностями и желаниями заинтересованных сторон для достижения целей проекта. Его цель — заложить основу для определения содержания продукта и проекта и выполняется только один раз или только в заранее определенных точках проекта.
входить
Устав проекта
план управления проектом
План управления объемом.
План управления спросом.
План взаимодействия с заинтересованными сторонами.
файлы проекта
бизнес-план
Бизнес-документ, влияющий на процесс сбора требований, — это экономическое обоснование, в котором описываются необходимые, ожидаемые и дополнительные стандарты, которым необходимо соответствовать для удовлетворения потребностей бизнеса.
протокол
факторы деловой среды
Активы организационного процесса
*Инструменты и методы
экспертная оценка
Бизнес-анализ; анализ требований; требования к проектным документам из аналогичных предыдущих проектов;
*Сбор данных
Мозговой штурм
Интервью
Интервью – это формальные или неформальные методы получения информации посредством прямых бесед с заинтересованными сторонами.
Интервью обычно включает в себя задание респондентам заранее определенных и импровизированных вопросов и запись их ответов.
Часто разговор «один на один», но может включать нескольких интервьюеров и/или нескольких интервьюируемых.
Интервью с опытными участниками проекта, спонсорами и другими руководителями, а также профильными экспертами помогают выявить и определить характеристики и функциональность требуемых результатов продукта. Интервью также можно использовать для получения конфиденциальной информации.
фокус-группа
Фокус-группа — это собрание заранее определенных заинтересованных сторон и экспертов в предметной области, чтобы понять их ожидания и отношение к рассматриваемому продукту, услуге или результату.
Обученный модератор ведет интерактивное обсуждение.
Анкета
Идеально подходит для ситуаций, когда ваша аудитория разнообразна, опросы необходимо проводить быстро, респонденты географически разбросаны и уместен статистический анализ.
Сравнительное сравнение см.
Сопоставимые организации, используемые для сравнительного анализа, могут быть внутренними или внешними.
анализ данных
*принятие решений
голосование
коллективное принятие решений
авторитарное принятие решений
Многокритериальный анализ решений
С помощью матрицы решений эта технология использует метод систематического анализа для установления различных критериев, таких как уровень риска, неопределенность и доходность, для оценки и ранжирования многих идей.
*Производительность данных
Диаграмма родства
Методы, используемые для группировки большого количества идей для дальнейшего рассмотрения и анализа.
картирование разума
* Межличностные и командные навыки.
метод номинальной группы
Оцените наиболее полезные идеи, проголосовав за дальнейший мозговой штурм или расстановку приоритетов.
Представьте вопрос или проблему группе. Каждый пишет свои мысли после размышления.
Модератор записывает идеи каждого на флипчарте.
Обсуждайте идеи, пока все участники не достигнут четкого консенсуса.
Люди голосуют конфиденциально, чтобы определить приоритетность идей, обычно по 5-балльной шкале, где 1 — самый низкий балл, а 5 — самый высокий.
наблюдать и говорить
Наблюдение и беседа — это прямое наблюдение за тем, как люди выполняют работу (или задачи) и реализуют процессы в своей соответствующей среде.
Когда пользователям продукта трудно или не хочется сформулировать свои потребности, наблюдение особенно необходимо, чтобы понять детали их работы.
Наблюдение, также известное как «слежение за работой», обычно включает в себя наблюдателя, наблюдающего за тем, как бизнес-эксперт выполняет свою работу, но за ним также может наблюдать «участник-наблюдатель», который испытывает процесс или процедуру, фактически выполняя ее. . Как это реализовать, чтобы обнаружить скрытые потребности.
гид
Фасилитация используется в сочетании с тематическими семинарами, чтобы собрать вместе ключевых заинтересованных сторон для определения требований к продукту.
Используется для быстрого определения межфункциональных требований и координации различий в требованиях между соответствующими сторонами.
Благодаря особенностям группового взаимодействия эффективно проводимые семинары могут помочь укрепить доверие, улучшить отношения и улучшить общение между участниками, тем самым помогая заинтересованным сторонам достичь консенсуса.
Руководящий сценарий
Совместное проектирование или разработка приложений (JAD) для сбора требований и улучшения процесса разработки программного обеспечения.
Развертывание функции качества (QFD). Производственная промышленность использует QFD в качестве вспомогательного навыка, помогающего определить ключевые характеристики новых продуктов. Потребности клиентов, также известные как «голос клиента», объективно классифицируют и ранжируют эти потребности, а также устанавливают цели для достижения этих потребностей.
Истории пользователей. Пользовательские истории — это краткие письменные описания требуемой функциональности, часто создаваемые на семинарах по разработке требований. Пользовательские истории описывают, какая заинтересованная сторона получит выгоду от функциональности (роль), чего ему нужно достичь (цель) и какие выгоды он ожидает получить (мотивация).
*Метод взаимодействия с системой
Диаграмма взаимодействия системы — это пример модели области, которая представляет собой визуальное изображение области применения продукта, показывающее бизнес-системы (процессы, оборудование, компьютерные системы и т. д.) и то, как они взаимодействуют с людьми и другими системами (субъектами).
Диаграмма взаимодействия системы показывает входы бизнес-системы, поставщиков входных данных, выходные данные бизнес-системы и получатели выходных данных.
* Метод прототипа
Определение: Создание прототипа желаемого продукта и получение ранних отзывов о требованиях до фактического производства продукта.
включая миниатюры, компьютерные 2D и 3D модели, физические модели или симуляции.
Прототип — это материальный объект, который позволяет заинтересованным сторонам испытать модель конечного продукта, а не ограничиваться обсуждением абстрактных описаний требований.
Метод прототипа поддерживает концепцию прогрессивной детализации и требует итерационного процесса от создания модели, взаимодействия с пользователем, сбора отзывов до модификации прототипа.
После достаточного количества циклов обратной связи через прототип можно получить достаточно информации о требованиях для перехода на этап проектирования или производства.
Раскадровка
Это технология прототипирования, которая показывает последовательность или путь навигации через серию изображений или диаграмм.
Раскадровки используются в различных проектах в различных отраслях, таких как кино, реклама, учебный дизайн, а также гибкие и другие проекты разработки программного обеспечения.
При разработке программного обеспечения в раскадровках используются макеты для иллюстрации пути навигации по веб-странице, экрану или другому пользовательскому интерфейсу.
выход
*Документ с требованиями
Определение: Опишите, как различные отдельные требования удовлетворят бизнес-потребности, связанные с проектом.
Он может начать только с требований высокого уровня, а затем постепенно уточнять их по мере увеличения информации о требованиях.
В качестве базового уровня могут служить только требования, которые являются ясными (измеримыми и тестируемыми), отслеживаемыми, полными, скоординированными и желающими быть признанными основными заинтересованными сторонами.
Документ с требованиями может быть в различных форматах: это может быть простой документ, в котором перечислены все требования, классифицированные по соответствующим сторонам и приоритетам, или это может быть подробный документ, включающий краткое изложение, подробные описания, приложения и т. д.
Требования делятся на различные категории, такие как бизнес-решения и технические решения. Первое относится к потребностям соответствующих сторон, а второе – к тому, как достичь этих потребностей.
Категория требований
Потребности бизнеса: потребности высокого уровня всей организации.
Потребности заинтересованных сторон
Требования к решению
Функциональные требования.
Функциональные требования описывают, что должен делать продукт, например, действия, процессы, данные и взаимодействия, которые должен выполнять продукт.
Нефункциональные требования.
Нефункциональные требования являются дополнением к функциональным требованиям и представляют собой условия окружающей среды или требования к качеству, необходимые для нормальной работы продукта, такие как надежность, конфиденциальность, производительность, безопасность, уровень обслуживания, возможность поддержки, сохранение или удаление и т. д.
Потребности в переходном периоде и готовности
Эти требования описывают временные возможности, необходимые для перехода от «текущего состояния» к «будущему состоянию», такие как потребности в преобразовании данных и обучении.
Требования к проекту
Действия, процессы или другие условия, которым должен соответствовать проект, например контрольные даты, договорные обязательства, ограничения и т. д.
требования к качеству
Любые условия или стандарты, используемые для подтверждения успешного завершения результатов проекта или достижения других требований проекта, таких как тестирование, сертификация, валидация и т. д.
*Метод отслеживания матрицы требований
Форма, которая связывает требования к продукту из их источников с результатами, удовлетворяющими этим требованиям.
Матрица прослеживаемости требований — это таблица, которая связывает требования к продукту от их источника до результатов, удовлетворяющих этим требованиям. Создание матрицы прослеживаемости требований, связывающей каждое требование с бизнес-целями или целями проекта, помогает гарантировать, что каждое требование имеет ценность для бизнеса.
Матрица отслеживания требований позволяет отслеживать требования на протяжении всего жизненного цикла проекта, помогая гарантировать, что каждое утвержденное требование в документе с требованиями может быть выполнено в конце проекта.
Наконец, матрица отслеживания требований также обеспечивает основу для управления изменениями содержания продукта.
категория
Бизнес-потребности, возможности, цели и задачи; объем проекта и результаты разработки продукта; стратегия тестирования и сценарии тестирования;
Соответствующие атрибуты каждого требования должны быть записаны в матрице отслеживания требований. Эти атрибуты помогают уточнить ключевую информацию каждого требования.
Типичные атрибуты, записанные в матрице отслеживания требований, включают уникальный идентификатор, текстовое описание требования, причину включения требования, владельца, источник, приоритет, версию, текущий статус (например, в работе, отменено, отложено, недавно добавлено, добавлено, утверждено, Назначено и Завершено) и дата статуса
Чтобы обеспечить удовлетворенность заинтересованных сторон, возможно, потребуется добавить дополнительные атрибуты, такие как стабильность, сложность и критерии приемки. В нем перечислены соответствующие атрибуты требований.
5.3 Определить область применения
Определение: Процесс разработки подробных описаний проектов и продуктов.
Процесс определения содержания выбирает окончательные требования проекта из документа требований (результат процесса сбора требований), а затем разрабатывает подробное описание проекта и его продуктов, услуг или результатов. Подготовка подробного описания содержания проекта имеет решающее значение для успеха проекта.
Подробное описание содержания проекта должно быть подготовлено на основе ключевых результатов, предположений и ограничений, задокументированных во время инициации проекта.
По мере получения дополнительной информации о проекте объем проекта должен быть определен и описан более подробно.
Необходимо проанализировать полноту существующих рисков, допущений и ограничений и внести необходимые дополнения или обновления.
Подробно спланируйте работу для следующей итерации, указав объем проекта и результаты текущей итерации.
входить
Устав проекта
Устав проекта содержит общее описание проекта, особенности продукта и требования к утверждению.
план управления проектом
Компоненты плана управления проектом включают (но не ограничиваются) план управления содержанием, который документирует, как содержание проекта будет определяться, проверяться и контролироваться.
файлы проекта
Успенский журнал. Документ требований. Реестр рисков.
факторы деловой среды
Активы организационного процесса
Инструменты и методы
экспертная оценка
анализ данных
принятие решений
Межличностные и командные навыки
*анализ продукта
Анализ продукта может использоваться для определения продуктов и услуг и включает в себя вопросы и ответы о продукте или услуге для описания цели, характеристик и других аспектов поставляемого продукта.
В каждой области приложения есть один или несколько общепризнанных методов преобразования высокоуровневых описаний продуктов или услуг в значимые результаты. Начните с сбора требований высокого уровня, а затем уточните их до уровня детализации, необходимого для окончательного проектирования продукта.
Технология анализа продукта:
Декомпозиция продукта; системный анализ; системный анализ стоимости;
выход
*Заявление об объеме проекта
Описание содержания проекта — это описание содержания проекта, ключевых результатов, допущений и ограничений.
В нем документируется весь объем, включая содержание проекта и продукта, а также подробные сведения о результатах проекта;
Это также отражает консенсус среди заинтересованных сторон проекта относительно масштабов проекта. Чтобы облегчить управление ожиданиями заинтересованных сторон, в описании содержания проекта можно четко указать, какие работы выходят за рамки проекта.
Заявление о содержании проекта позволяет команде проекта более детально планировать, направляет работу команды проекта во время выполнения и обеспечивает основу для оценки того, выходят ли запросы на изменения или дополнительная работа за границы проекта.
Уровень детализации, с которой описание содержания проекта описывает, что будет и что не будет сделано, определяет, насколько эффективно команда управления проектом может контролировать весь объем проекта.
содержание
Описание ассортимента продукции. Практические результаты. Критерии приемки. Исключения проекта.
Несмотря на некоторую степень совпадения содержания устава проекта и описания содержания проекта, их уровень детализации совершенно различен. Устав проекта содержит информацию высокого уровня, тогда как описание содержания проекта представляет собой подробное описание компонентов. объем, который необходимо реализовать в проекте. Прогрессивные детали в ходе процесса.
Обновления файлов проекта
5.4 Создание СДР
Процесс разбиения результатов проекта и работ по проекту на более мелкие, более управляемые компоненты. комплекс работ
WBS представляет собой иерархическую разбивку всего объема работ, которые команда проекта должна выполнить для достижения целей проекта и создания необходимых результатов.
WBS организует и определяет общий объем проекта и представляет работы, указанные в утвержденном текущем описании содержания проекта.
Компонент самого низкого уровня называется пакетом работ и содержит запланированные работы. Пакеты работ классифицируют связанные действия для планирования, оценки, надзора и контроля работы.
В термине «структура декомпозиции работ» «работа» относится к рабочим продуктам или результатам, которые являются результатом деятельности, а не к самим действиям.
Степень декомпозиции зависит от требуемой степени контроля. Уровень детализации пакета работ будет варьироваться в зависимости от размера и сложности проекта.
входить
план управления проектом
файлы проекта
Заявление об объеме проекта. Документ требований.
факторы деловой среды
Стандарты WBS для отрасли, в которой находится проект. Эти стандарты можно использовать в качестве внешних справочных материалов для создания WBS.
Активы организационного процесса
Инструменты и методы
экспертная оценка
авария
Декомпозиция — это метод постепенного разделения содержания проекта и результатов проекта на более мелкие, более управляемые компоненты.
Определить и проанализировать результаты работ и связанные с ними работы; определить структуру и метод организации WBS; уточнить декомпозицию сверху вниз; разработать и присвоить идентификационные коды компонентам WBS; проверить, является ли степень декомпозиции результатов работы подходящей;
Как создать WBS
Подход к декомпозиции сверху вниз, проверка снизу вверх с использованием рекомендаций, специфичных для организации, и шаблонов WBS.
Каждый этап жизненного цикла проекта используется как второй уровень декомпозиции, а продукты и результаты проекта размещаются на третьем уровне.
Если основные результаты являются вторым уровнем декомпозиции,
Включите различные компоненты более низкого уровня, разработанные организациями, не входящими в проектную группу (например, аутсорсинговые работы). В дальнейшем в рамках аутсорсинговых работ продавец должен подготовить соответствующий договор WBS.
выход
Базовый уровень объема
Описание содержания проекта, пакет работ, WBS, пакет планирования
Словарь WBS
Это документ, в котором подробно описываются результаты, мероприятия и информация о ходе реализации каждого компонента WBS. Словарь WBS обеспечивает поддержку WBS, где большая часть информации создается другими процессами, а затем добавляется в словарь на более позднем этапе.
Обновления файлов проекта
контроль
Подтвердите область действия
Процесс формальной приемки завершенных результатов проекта. Этот процесс должен выполняться регулярно на протяжении всего проекта по мере необходимости.
входить
план управления проектом
План управления объемом. План управления спросом. Эталон масштаба.
файлы проекта
Зарегистрируйте извлеченные уроки. Качественная отчетность. Документ требований. Матрица отслеживания требований.
Проверенные результаты
Относится к результату, который был завершен и проверен на правильность в процессе контроля качества.
данные о производительности труда
Сюда может входить степень выполнения требований, количество несоответствий, серьезность несоответствий или количество проверок, выполненных в течение определенного периода времени.
Инструменты и методы
исследовать
Чтобы определить, соответствуют ли работа и результаты требованиям и стандартам приемки продукции, проверки иногда называют проверками, проверками продукции, проверками и т. д.
принятие решений
выход
*Результаты для приемки
Результаты, соответствующие критериям приемки, должны быть официально подписаны клиентом или спонсором.
информация о производительности труда
запрос на обновление
Обновления файлов проекта
Диапазон управления
Отслеживайте состояние проекта и содержания продукта и управляйте процессом изменения базового плана содержания.
Основная функция заключается в поддержании базового уровня содержания на протяжении всего проекта, и ее необходимо выполнять на протяжении всего проекта.
входить
план управления проектом
План управления объемом. План управления спросом. План управления изменениями. План управления конфигурацией. Эталон масштаба. Тесты измерения производительности.
файлы проекта
данные о производительности труда
Активы организационного процесса
Инструменты и методы
анализ данных
Анализ отклонений. анализ тенденций.
Определение причин и степени отклонений от базового плана содержания и принятие решения о необходимости принятия корректирующих или предупреждающих действий являются важными задачами контроля содержания проекта.
выход
информация о производительности труда
Запрос на изменение
Обновление плана управления проектом
Обновления файлов проекта
Если приемка завершена и появились ошибки, необходимы доработки. Если заказчик добавит требования, доработки не будут приняты и перейдут на следующий этап.
Великие менеджеры по проектам используют экспертные суждения, новички используют декомпозицию
Документ с требованиями подается на корректуру