Отчетность по статусу конфигурации. При необходимости предоставления соответствующих данных об элементе конфигурации информация документируется, и по ней составляется отчет. Такая информация включает список одобренных идентифицированных элементов конфигурации, статус предложенных изменений конфигурации и статус реализации одобренных изменений.
Подтверждение и аудит конфигурации. Подтверждение и аудиты конфигурации позволяют убедиться, что структура элементов конфигурации проекта является верной, а соответствующие изменения зарегистрированы, оценены, одобрены, отслежены и надлежащим образом реализованы. Это гарантирует соблюдение функциональных требований, определенных в документации по конфигурации.
Управление содержанием проекта
Управление содержанием проекта включает в себя процессы, требуемые для обеспечения того, чтобы проект содержал все и только те работы, которые требуются для успешного выполнения проекта. Управление содержанием проекта непосредственно связано с определением и контролем того, что включено и что не включено в проект.
В контексте проекта термин «содержание» может обозначать:
Содержание продукта. Свойства и функции, которые характеризуют продукт, услугу или результат.
Содержание проекта. Работы, которые необходимо выполнить, чтобы получить продукт, услугу или результат с заданными свойствами и функциями. Термин «содержание проекта» иногда включает в себя содержание продукта.
Классы требований:
Бизнес-требования, описывающие высокоуровневые потребности организации в целом, например, проблемы или благоприятные возможности организации, а также причины, по которым проект был предпринят.
Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон.
Требования к решению, описывающие свойства, функции и характеристики продукта, услуги или результата, который удовлетворит бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группируются в функциональные и нефункциональные требования:
Функциональные требования описывают поведение продукта. Примеры включают в себя процессы, данные и взаимодействия с продуктом.
Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д.
Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем.
Требования к проекту описывают действия, процессы или другие условия, которым должен соответствовать проект.
Требования к качеству, включающие в себя любое состояние или критерий, необходимые для подтверждения успешного получения поставляемого результата проекта или выполнения других требований к проекту.
Управление сроками проекта
Управление сроками проекта включает в себя процессы, необходимые для того, чтобы обеспечить своевременное выполнение проекта.
Типы зависимости операций:
Финиш-старт (finish-start, FS). Логическая связь, при которой старт последующей операции зависит от финиша предшествующей операции. Пример: церемония награждения (последующая операция) не может быть начата, пока не закончится гонка предшествующая операция).
Финиш-финиш (finish-finish, FF). Логическая связь, при которой финиш последующей операции зависит от финиша предшествующей операции. Пример: создание документа (предшествующая операция) должно быть закончено до завершения его правки (последующая операция).
Старт-старт (start-start, SS). Логическая связь, при которой старт последующей операции зависит от старта предшествующей операции. Пример: выравнивание бетонной поверхности (последующая операция) не может начаться до начала заливки фундамента (предшествующая операция).
Старт-финиш (start-finish, SF). Логическая связь, при которой финиш последующей операции зависит от старта предшествующей операции. Пример: первая смена службы охраны (последующая операция) не может закончиться, пока не начнется вторая смена службы охраны (предшествующая операция).
Оценка по трем точкам
Точность оценок длительности операций по одной точке может быть улучшена путем рассмотрения неопределенностей оценок и рисков. Данная концепция происходит из метода оценки и анализа программ (program evaluation and review technique, PERT). Для определения приблизительного диапазона длительности операции PERT использует три оценки:
Наиболее вероятная (tM). Длительность операции определяется с учетом предварительного выделения ресурсов, их производительности, реалистичной оценки их доступности для выполнения данной операции, зависимостей от других участников, а также с учетом прерываний в работе.
Оптимистичная (tO). Длительность операции основывается на анализе наиболее благоприятного сценария для операции.
Пессимистичная (tP). Длительность операции основывается на анализе наиболее неблагоприятного сценария для операции.
Будучи зависимой от предполагаемого распределения значений в диапазоне трех оценок, ожидаемая длительность, tE, рассчитывается по формуле. Две наиболее распространенные формулы треугольное распределение и бета-распределение.
Формулы:
Треугольное распределение. tE = (tO + tM + tP) / 3
Бета-распределение (из традиционного метода PERT). tE = (tO +4tM + tP) / 6
Метод критического пути
Метод критического пути метод, используемый для оценки минимальной длительности проекта и определения степени гибкости расписания на логических путях в сети в рамках модели расписания. Метод анализа сети расписания позволяет рассчитать даты раннего старта и финиша, а также даты позднего старта и финиша для всех операций без учета ресурсных ограничений путем проведения анализа прямого и обратного прохода по сети проекта, как показано на рис. 618. В данном примере самый длительный путь включает в себя операции A, C и D, и поэтому последовательность A-C-D является критическим путем. Критический путь это последовательность операций, представляющая собой самый длительный путь в расписании проекта, который определяет самую короткую возможную длительность проекта. Полученные даты раннего старта и финиша не обязательно являются расписанием проекта; они скорее указывают периоды времени, в рамках которых может быть выполнена операция, используя параметры, введенные в модель расписания, связанные с длительностью операций, логическими связями, опережениями, задержками и другими известными ограничениями. Метод критического
пути используется для расчета степени гибкости расписания на логических путях в сети в рамках модели расписания.
Метод критической цепи
Метод критической цепи (CCM) метод разработки расписания, позволяющий команде проекта размещать буферы на любом пути в расписании, чтобы учесть ограниченность ресурсов и неопределенности, связанные с проектом. Он разработан из метода критического пути и учитывает воздействия распределения, оптимизации, выравнивания ресурсов, а также
неопределенность в отношении длительности операции на критическом пути, определенном методом критического пути. Метод критической цепи включает в себя понятия буферов и управления буферами. Метод критической цепи использует операции, длительность которых не включает в себя пределы безопасности, логические связи и доступность ресурсов со
статистически определенными буферами, включающими в себя суммарные пределы безопасности операций в определенных точках проекта на пути расписания проекта для учета ограниченных ресурсов и неопределенности, связанной с проектом. Критический путь с ресурсными ограничениями известен как «критическая цепь».
Управление стоимостью проекта
Управление стоимостью проекта включает в себя процессы, необходимые для планирования, оценки, разработки бюджета, привлечения финансирования, финансирования, управления и контроля стоимости, обеспечивающие исполнение проекта в рамках одобренного бюджета.