Часть 4. Планирование проекта*

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

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

CMMI включает в управление проектами следующие области процессов:

  • планирование проекта;
  • контроль и мониторинг проекта;
  • управление поставщиками;
  • интегрированное управление проектом;
  • управление рисками;
  • количественное управление проектом.

Планирование проекта, его контроль и мониторинг и управление поставщиками относятся ко второму уровню зрелости. Управление рисками относится к третьему уровню зрелости и, наконец, количественное управление проектом — к четвертому уровню.

Очередная статья нашего цикла посвящена процессу планирования проекта.

Задача области процессов «Планирование проекта» — установить и поддерживать планы, в которых определены все необходимые для выполнения проекта действия. Общая схема процесса «Планирование проекта приведена на рис. 1.

Рис. 1. Общая схема планирования проекта

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

В CMMI широко используется термин план проектаp. В данное понятие включаются план управления проектом, план управления рисками, план измерений, план обучения и т.д.

Для установления эффективного процесса планирования CMMI рекомендует:

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

Оценка объема проекта

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

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

Общая схема процесса оценок представлена на рис. 2.

Авторы модели CMMI настоятельно рекомендуют проводить оценку объема проекта на основе структуры работ (work breakdown structure, WBS). Ее определение — важный элемент планирования, поскольку весь проект декомпозируется на комплекс взаимосвязанных управляемых компонентов. Целесообразно разрабатывать структуру работ на основе архитектуры продукта. Это позволяет выделить логические элементы работ, так называемые «рабочие пакеты», каждый из которых может управляться автономно. Как правило, WBS развивается, дополняется и уточняется по мере выполнения проекта, поэтому при первоначальных оценках целесообразно использовать структуру работ верхнего уровня.

Рис. 2. Исходные оценки

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

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

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

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

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

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

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

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

Определение жизненного цикла проекта

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

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

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

Рекомендуемые рабочие продукты — результаты данного этапа: описание фаз жизненного цикла проекта.

Оценка трудозатрат и стоимости

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

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

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

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

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

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

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

Установление бюджета и графика

Установление бюджета и графика — первый шаг в разработке плана проекта. Общая схема разработки плана проекта представлена на рис. 3.

Рис. 3. Схема разработки плана проекта

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

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

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

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

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

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

Рекомендуемые рабочие продукты — результаты данного этапа: график проекта; критический путь; бюджет проекта.

Определение проектных рисков

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

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

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

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

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

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

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

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

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

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

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

Планирование ресурсов

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

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

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

Рекомендуемые рабочие продукты — результаты данного этапа: рабочие пакеты структуры работ; словарь задач WBS; требования к людским ресурсам; перечень критически важного оборудования и производственных площадей; описания и диаграммы процессов; перечень требований к администрированию проекта.

Планирование требуемых знаний и навыков

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

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

Рекомендуемые рабочие продукты — результаты данного этапа: перечень требуемых знаний; планы укомплектования проектной команды; планы найма нового персонала; базы данных (например, навыки и обучение).

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

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

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

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

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

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

Рекомендуемые рабочие продукты — результаты данного этапа: список заинтересованных лиц; матрица вовлеченности; роли и ответственности в проекте.

Установление плана проекта

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

Анализ планов

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

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

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

Рекомендуемые рабочие продукты — результаты данного этапа: рекомендуемые рабочие продукты, записи об анализе планов.

Согласование уровней работ и ресурсов

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

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

Получение обязательств участников по выполнению плана

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

Очень часто «обязательство» интерпретируют как обязанность и отождествляют с возложением обязанностей по выполнению работы. Модель CMMI вкладывает другое содержание в этот термин. Понятие «обязательство» означает, что работа понятна исполнителю, что он считает эту работу разумной и выполнимой, что он принимает на себя обязательство выполнить эту работу в срок и наилучшим образом. Можно обязать сотрудника выполнить то или иное задание, но трудно ожидать, что он приложит все силы и умение для выполнения задания. Скорее надо приготовиться к объяснениям по поводу того, почему данная работа не могла быть выполнена.

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

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

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

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

Рекомендуемые рабочие продукты — результаты данного этапа: документированные запросы на принятие обязательств; документированные обязательства.

Литература.
  1. CMMI-SE/SW Version 1.1, Staged Representation, Technical Report CMU/SEI-2002-TR-012, SEI.
  2. CMMI-SE/SW Version 1.1, Continuous Representation, Technical Report CMU/SEI-2002-TR-012, SEI.
  3. Boris Mutafelija, Harvey Stromberg, Systematic Process Improvement Using ISO 9001:2000 and CMMI. SEI, 2003.
  4. Interpreting Capability Maturity Model Integration (CMMI) for Service Organizations. Technical Note CMU/SEI-2003-TN-005, 2003.
  5. CMMI Interpretive Guidance Project. Special Report CMU/SEI-2003-SR-007.
  6. Bruce Allgood, Mile Phillips, CMMI v.1.1 Tutorial. SEI, 2002.

Кирилл Мильман (kmilman@regent.ru) — руководитель службы управления качеством холдинговой компании «Регент», Семен Мильман (smilman@ibs.ru) — директор по качеству Центра аутосорсинга Datafort группы компаний IBS.

Новое в CMMI

Институт программной инженерии Университета Карнеги—Меллон официально объявил об изменениях в системе асесмента (appraisal — «оценка») предприятий на соответствие модели Capability Maturity Model Integration.

Модель CMMI 1.1 была выпущена в декабре 2001 года. С тех пор во всем мире проведено более тысячи оценок.

На основании накопленного опыта и отзыва компаний, успешно внедривших CMMI, в действующую модель были внесены существенные усовершенствования; в августе 2006 года предполагается выпустить новую редакцию модели — CMMI 1.2.

С выходом CMMI версия 1.2 начнется постепенное «отмирание» модели CMMI версии 1.1. Период замены старой модели новой завершится 31 декабря 2007 года.

Все оценки, проведенные после 31 декабря 2007 года, будут приняты, только если они будут проведены в соответствии CMMI 1.2.

После 31 декабря 2007 года оценки по модели CMMI 1.1 не будут приниматься к рассмотрению. В то же время в период до 31 декабря 2007 года будут приниматься к рассмотрению оценки по модели CMMI 1.1 с учетом требований CMMI 1.2.

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

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

Институт программной инженерии официально объявил, что опубликованные ранее результаты оценок (seir.sei.cmu.edu/pars/) будут удалены по истечении трех лет после даты оценки или через один год после публикации CMMI 1.2 в зависимости от того, какое событие настанет раньше.

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

Продолжение. См. начало в выпусках журнала «Открытые системы», 2005, № 5-6, 7-8, 9.