Модель зрелости процессов разработки программного обеспечения

2.2. Понимание концепций уровней зрелости

      CMM представляет собой описательную модель, поскольку она описывает существенные (или ключевые) атрибуты, которые, как предполагается, должны характеризовать организацию определенного уровня зрелости. Это модель является нормативной в том смысле, что подробные практики характеризуют обычные виды поведения, ожидаемого от организации, ведущей крупномасштабные проекты по государственным заказам. Обратите внимание, что CMM представляет собой достаточно высокий уровень абстракции и не выдвигает чрезмерных ограничений к способам реализации производственного процесса организации — эта модель просто описывает необходимые существенные атрибуты производственного процесса.
      В любом контексте применения CMM следует разумно интерпретировать рекомендуемые практики. В том случае, когда бизнес-среда организации значительно отличается от среды крупной контрактной компании, модель CMM должна быть корректно интерпретирована с использованием информированных профессиональных оценок. CMM не является предписанием, в этой модели нет советов по способам усовершенствования организации. CMM описывает организацию на каждом уровне зрелости без предписания конкретных способов их достижения. Переход с уровня 1 на уровень 2 может занять несколько лет, а переход по остальным уровням обычно занимает около двух лет.
      Усовершенствование производственного процесса происходит в контексте бизнес-целей и стратегических планов организации, ее организационной структуры, используемых технологий, социальной культуры и системы управления. CMM фокусируется на аспектах процессов тотального управления качеством (TQM). Успешное усовершенствование процессов подразумевает также учет вопросов вне рамок производственного процесса (например, проблемы с персоналом, которые возникают из-за изменений организационной культуры, предпринимаемых с целью внедрения и институционализации усовершенствований процессов).

2.2.1. Понимание концепции начального уровня

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

2.2.2. Понимание повторяемого и определенного уровней

      По мере роста объема и сложности проекта, внимание постепенно смещается от технических вопросов к организационным и управленческим — т. е. к вопросам, которые находятся в фокусе рассмотрения модели зрелости процессов [Siegel 90, DoD 87, GAO-92-48]. Производственный процесс на этих уровнях позволяет сотрудникам работать более эффективно благодаря созданию документированных процессов, включающих в себя опыт наилучших работников, обретения навыков, необходимых для эффективного выполнения процессов (обычно с помощью обучения), и непрерывного совершенствования за счет обучения у сотрудников, реально выполняющих работу.
      Для достижения уровня 2 руководство должно сфокусировать внимание на своих собственных процессах, добиваясь установления дисциплинированного производственного процесса. Уровень 2 формирует основу для уровня 3, так как внимание сосредоточено на руководстве, которое стремится усовершенствовать свои процессы прежде, чем приступить к техническим и организационным вопросам на уровне 3. На уровне 2 руководство занимает лидирующее положение путем документирования и следования процессам управления проектом.
      Процессы организаций второго уровня могут различаться от проекта к проекту. Организационные требования для достижения уровня 2 заключаются в формировании политик, помогающих установить в проектах соответствующие процессы управления. Документированные процедуры обеспечивают основу для согласованных процессов, которые могут быть установлены в рамках всей организации с помощью обучения и мероприятий по обеспечению качества ПО.
      На этом фундаменте управления проектом строится уровень 3, который определяет, интегрирует и документирует весь производственный процесс организации. Под интеграцией в этом случае понимается процесс автоматической передачи выходных данных одной задачи на вход другой. Несоответствия между задачами выявляются и разрешаются на стадии планирования процесса до их фактического воздействия на производственный процесс. Одной из проблем уровня 3 является построение таких процессов, которые не содержат излишних ограничений на выполнение сотрудниками своей работы [Humphrey 91b].

2.2.3. Понимание управляющего и оптимизированного уровней

      Четвертый и пятый уровни зрелости относительно незнакомы для программной отрасли. Существуют лишь несколько примеров проектов разработки и организаций уровня 4 и 5 [Humphrey 91a, Kitson 92]. Для создания общей картины характеристик организаций этих уровней имеется слишком мало данных. Эти характеристики были определены по аналогии с другими отраслями промышленности и по нескольким примерам из программной отрасли, представляющими данный уровень продуктивности процессов.
      Многие характеристики уровней 4 и 5 основаны на концепциях статистического управления процессами, как представлено на рис. 2.2. Основные цели управления процессами иллюстрируются трехфазной диаграммой Джурана [Juran 88].
      Джуран разделяет управление качеством на три основных управленческих процесса [Juran 88]. Целью планирования качества является обеспечение разработчиков ПО средствами создания продукта, способного удовлетворить потребности заказчика. Разработчики производят продукт, но вследствие недостатка качества требуется провести некоторую доработку. Подобная трата сил носит хронический характер, потому что процесс именно так и запланирован. Для предотвращения серьезного ухудшения состояния проекта проводится контроль качества. Показанные на рис. 2.2 спорадические перепады процесса отражают операции «пожаротушения». Хроническая трата сил дает потенциал для дальнейшего усовершенствования; использование этой возможности называется улучшением качества.
      Основной задачей и центром внимания уровня 4 является контроль над процессом. Производственный процесс управляется таким образом, что он стабильно функционирует внутри области контроля качества. Существуют некоторые неизбежные хронические потери ресурсов и возможен разброс измеренных результатов, которые следует контролировать, но в целом система достаточно стабильна. В этом случае применяется концепция управления особыми причинами отклонений. Поскольку процесс стабилен и измеряем, то при возникновении исключительной ситуации «особая причина» отклонения должна быть выявлена и устранена.
      Второй задачей и центром внимания уровня 5 является постоянное усовершенствование процесса. Производственный процесс изменяется с целью увеличения качества, а область контроля качества сдвигается. Устанавливается новая базовая линия производительности, уменьшающая хронические потери ресурсов. Опыт, извлеченный из улучшения подобного процесса, применяется в планировании будущих процессов. В этом случае используется концепция устранения общих причин отклонений. В любой системе из-за случайных отклонений существуют хронические потери ресурсов в виде необходимости доработки. Потери неприемлемы; организованные усилия по их предотвращению приводят к изменению системы, т. е. к усовершенствованию процесса путем изменения «общих причин» неэффективности.
      Ожидается, что организации, достигающие наиболее высоких уровней зрелости CMM, должны обладать процессом, который способен производить ПО высокой надежности с предсказуемыми затратами и в пределах рабочих графиков. По мере роста понимания того, как достигаются наиболее высокие уровни зрелости, одни существующие группы ключевых процессов будут уточнены, а другие могут быть добавлены в модель. Концепция CMM произошла из идей о процессах, впервые появившихся в промышленности, но, в отличие от промышленных процессов, процессы разработки не заостряют внимание на тиражировании своей продукции — они нацелены на вопросы проектирования и являются наукоемкой деятельностью [Curtis 88].
 

 
      Рис. 2.2. Трехфазная диаграмма Джурана: планирование, контроль и улучшение качества

2.3. Представление о производственном процессе

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

 
      Рис. 2.3. Представление руководства о производственном процессе на каждом уровне зрелости
      На уровне 1 производственный процесс является полностью аморфной сущностью — по сути дела, черным ящиком — и представление о процессах проекта весьма ограничено. Так как поэтапная очередность работ плохо определена, менеджеры тратят чрезвычайно много усилий на выяснение статуса развития проекта и текущего хода работ (эти оценки могут проводиться и без получения полной информации, если ее сбор затрагивает вопросы конфиденциальности или безопасности организации).
      Требования поступают в производственный процесс неконтролируемым образом, что отражается на продукте. Разработка ПО часто представляется чем-то сродни черной магии (особенно менеджерами, слабо знакомыми с программным обеспечением).
      На уровне 2 контролируются требования заказчиков и промежуточные продукты, а также установлены основные практики управления проектом. Эти средства управления проектом дают фрагментарное представление о нем. Процесс создания ПО может рассматриваться как последовательность черных ящиков, дающая руководству представление о результатах только во время перехода операций между ящиками (т. е. при прохождении основных этапов проекта). Хотя руководство может и не быть в курсе относительно происходящего в черных ящиках, продукты процесса и контрольные точки, подтверждающие функционирование процесса, идентифицированы и известны. Руководство реагирует на проблемы по мере их возникновения.
      На уровне 3 становится видимой внутренняя структура черных ящиков, т. е. задач определенного производственного процесса. Эта внутренняя структура отражает способ, применения стандартного производственного процесса организации для конкретного проекта. Как менеджеры, так и инженеры понимают свои роли и сферы ответственности в пределах процесса и то, как их операции взаимодействуют друг с другом. Руководство заблаговременно готовится к потенциальным рискам. Лица, не задействованные в проекте, могут получить точное и быстрое обновление сведений о состоянии проекта, так как определенные процессы обеспечивают значительную прозрачность всех проектных работ.
      На уровне 4 определенные производственные процессы количественно контролируются с помощью соответствующих программных средств. Менеджеры могут количественно отслеживать ход проекта и возникающие проблемы. Они получают объективную количественную основу для принятия решений. Точность прогнозирования результатов неуклонно увеличивается по мере уменьшения отклонений производственного процесса.
      На уровне 5 постоянно тестируются контролируемым образом новые и усовершенствованные технологии создания программного обеспечения, нацеленные на рост продуктивности и качества. Дисциплинированные изменения становятся образом жизни, а неэффективные и приводящие к дефектам операции выявляются, заменяются и пересматриваются. Представление о проекте не ограничивается существующими процессами, но также учитывает их потенциальные изменения. Менеджеры могут количественно оценить и затем отследить влияние и эффективность изменений.

2.4. Продуктивность процесса и прогнозирование производительности

      Зрелость производственного процесса организации помогает предсказать, сумеет ли проект достичь поставленных целей. Проекты организаций, находящихся на уровне 1, могут значительно различаться по затратам и графикам, а также по функциональности и качеству созданного продукта. Как показано на рис. 2.4, по мере развития производственного процесса наблюдаются три основных улучшения в достижении намеченных целей.
      Прежде всего, с ростом зрелости уменьшаются различия между целевыми и фактическими результатами. Например, если десять проектов одного и того же размера было намечено завершить к 1 мая, то с ростом зрелости организации средняя дата завершения будет все точнее соответствовать намеченной дате. Организации 1-го уровня зрелости часто не соблюдают установленные сроки завершения работ, и иногда в достаточно широких пределах, в то время как организации уровня 5 должны быть способны выполнить работы точно к намеченному сроку. Подобное происходит потому, что организации уровня 5 используют тщательно разработанный производственный процесс, проводимый с известными параметрами, а выбор целевой даты основан на обширных данных о процессах и их производительности (рис. 2.4, эффект соответствует площади под кривой для сегмента, расположенного справа от целевой линии).
      Во-вторых, с ростом уровня зрелости уменьшаются отклонения фактических результатов от запланированных. Например, для организаций уровня 1 даты завершения проектов аналогичного объема непредсказуемы и могут варьироваться в достаточно широких пределах. Подобные проекты, выполняемые организациями уровня 5, будут завершаться со значительно меньшим разбросом сроков. Сужение отклонения происходит на более высоких уровнях зрелости, потому что практически все проекты выполняются с соблюдением контролируемых параметров, уравнивающих разброс продуктивности производственного процесса организации по затратам, графикам работ, а также функциональности и качеству разработанного ПО (рис. 2.4, эффект соответствует сегменту площади под кривой, сконцентрированному вблизи целевой линии).
      В-третьих, результаты улучшаются с ростом уровня зрелости организации. Это означает, что развитие организации-разработчика позволяет сократить затраты, ускорить процесс разработки, повысить производительность работы и качество программных продуктов. Процесс разработки у организации уровня 1 может быть достаточно длительным из-за объема доработки, требующейся для исправления ошибок. В противоположность этому организация 5-го уровня зрелости может использовать технологии непрерывного усовершенствования процесса и предотвращения дефектов в целях повышения эффективности производственного процесса и устранения дорогостоящей доработки, что позволяет сократить срок разработки (рис. 2.4, горизонтальное смещение целевой линии от исходного состояния).
 

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

2.5. Пропуск этапов развития организации

      Описания уровней зрелости в СММ содержат характеристики организации, достигшей соответствующего уровня. Каждый уровень образует основу для более рациональной и эффективной реализации процессов на последующих уровнях. Однако организации могут с пользой для себя использовать процессы, описанные на уровнях зрелости, более высоких в сравнении с достигнутыми. Такие технологические процессы, как анализ требований, проектирование, кодирование и тестирование не обсуждаются в СММ вплоть до уровня 3, однако эти операции должны выполняться даже организациями первого уровня. Организации уровней 1 и 2 могут получать преимущества от проведения экспертных оценок (уровень 3), выполнения анализа Парето (уровень 4) или испытаний новых технологий (уровень 5). Предписания по переходу организации с уровня 1 на уровень 2 часто содержат рекомендации по созданию группы инженерии производственного процесса, которая является атрибутом организаций уровня 3. Измерения, хотя и описываются в основном на уровне 4, являются также неотъемлемой частью более низких уровней зрелости.
      Однако эти процессы не могут реализовать весь свой потенциал до тех пор, пока для них не будет заложен соответствующий фундамент. Например, чтобы достигнуть максимальной эффективности экспертных оценок, необходимо проводить их последовательно даже в самых критических ситуациях. В описания уровней зрелости входят те проблемы, которые доминируют на соответствующем уровне. В организации первого уровня доминируют управленческие проблемы, остальные вопросы скрываются за сложностями планирования и управления проектами разработки ПО.
      Пропуск уровней зрелости нежелателен, поскольку каждый уровень формирует основу, необходимую для достижения следующего уровня. Модель СММ определяет уровни, через которые должно пройти развитие организации прежде, чем она сможет создать культуру высокоэффективной разработки ПО. Процессы, не имеющие соответствующего фундамента, могут подвести в наиболее критические моменты и не создают основы для дальнейшего усовершенствования.
      Попытки организации первого уровня внедрить определенный производственный процесс (уровень 3) раньше, чем будет установлен повторяемый процесс (уровень 2), обычно заканчиваются неудачей, поскольку менеджеры проектов попадают в крайне жесткие условия графика и бюджета. В этом кроется основная причина для того, чтобы сконцентрировать усилия на процессах управления прежде, чем заниматься инженерными процессами. Определение и внедрение инженерного процесса может показаться более простым, чем внедрение процесса управления (особенно с точки зрения технических сотрудников), но без строгой дисциплины управления инженерный процесс разваливается под давлением сроков и бюджета [Humphrey 88].
      Обычно безуспешными являются попытки организации реализовать управляемый процесс (уровень 4) до внедрения определенного процесса, поскольку определенные процессы формируют общую основу для интерпретации измерений. Хотя сбор данных может вестись для отдельных проектов, лишь немногие измерения оказываются значимыми для всех проектов и они не могут существенно повлиять на понимание производственного процесса в рамках организации. В отсутствие определенных процессов сложно идентифицировать значимые измерения из-за отклонений в измеряемых процессах.
      Успешное внедрение оптимизирующего процесса (уровень 5) без наличия управляемого процесса (уровень 4) также маловероятно из-за недостаточного понимания влияния, вносимого изменениями процессов.
      Без контролирования процесса в узких статистических границах (т. е. с малыми отклонениями количественных показателей процесса), его данные содержат слишком много шума, чтобы можно было объективно определить эффект, производимый конкретным усовершенствованием процесса. Принятие решений может вылиться в религиозные войны, поскольку для рациональных и обоснованных решений недостаточно количественной информации.
      Работа по усовершенствованию процесса должна быть нацелена прежде всего на нужды организации в контексте ее бизнес-среды. Возможность реализовать процессы более высоких уровней вовсе не означает, что организация может перейти на произвольный уровень зрелости.

ГЛАВА 3. РАБОЧЕЕ ОПРЕДЕЛЕНИЕ МОДЕЛИ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПО

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

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

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

 
      Рис. 3.1. Структура CMM

3.2. Уровни зрелости

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

3.3. Группы ключевых процессов

      Каждый уровень зрелости, кроме первого, состоит из нескольких групп ключевых процессов, указывающих на области концентрации усилий по совершенствованию производственного процесса организации. Группы ключевых процессов определяют круг проблем, которые необходимо решить для достижения следующего уровня зрелости.
      Каждая группа ключевых процессов определяет блок связанных работ, после выполнения которых достигается совокупность целей, значимых для повышения продуктивности производственного процесса. Группы ключевых процессов определяются таким образом, что они целиком входят в один уровень зрелости, как показано на рис. 3.2. Способ достижения целей группы ключевых процессов может различаться от проекта к проекту в зависимости от различий в предметной области или среде, однако все эти цели являются обязательными для организации. После того, как эти цели будут реализованы на постоянной основе для всех проектов, можно будет сказать, что организация установила уровень продуктивности своего производственного процесса, характеризующийся данной группой ключевых процессов.
      Прилагательное «ключевые» подразумевает, что существуют процессы и группы процессов, которые не являются ключевыми для достижения уровня зрелости. Модель СММ не описывает подробно все группы процессов, касающиеся разработки и сопровождения ПО. В ней описаны лишь те группы, которые определены в качестве ключевых определяющих факторов продуктивности производственного процесса.
      Хотя производительность процесса зависит от многих факторов, группы ключевых процессов выделяются по своей эффективности в повышении продуктивности производственного процесса организации. Их можно рассматривать, как требования для достижения уровня зрелости. На рис. 3.2 показаны группы ключевых процессов для каждого уровня. Для достижения определенного уровня зрелости необходимо реализовать соответствующие группы ключевых процессов, для чего, в свою очередь, требуется достижение всех целей соответствующих групп. Цели подытоживают ключевые практики группы и могут служить критерием эффективной реализации группы ключевых процессов в организации. Они выражают объем, границы и смысл каждой группы ключевых процессов (Список целей каждой группы ключевых процессов приводится в Приложении).
 

 
      Рис. 3.2. Распределение групп ключевых процессов по уровням зрелости
      Конкретные практики, подлежащие выполнению в каждой группе ключевых процессов, эволюционируют по мере достижения организацией более высоких уровней зрелости. Например, многие средства оценки проекта, описанные в группе ключевых процессов «Планирование проекта» на уровне 2, должны быть модернизированы для обработки дополнительных данных по проекту, доступных на уровнях 3–5. «Интегрированное управление разработкой ПО» на уровне 3 является развитием групп «Планирование проекта» и «Отслеживание хода проекта и контроль над ним» уровня 2, поскольку управление проектом осуществляется с использованием определенного производственного процесса.
      Группы ключевых процессов модели СММ представляют единый способ описания развития организаций. Эти группы были определены на основании многолетнего опыта управления разработкой ПО, а также пятилетнего опыта в проведении внутренних и внешних оценок производственного процесса.
      Группы ключевых процессов уровня 2 связаны в основном с вопросами создания основных средств управления проектом. Ниже приводятся описания всех групп ключевых процессов уровня 2.
      Цель группы ключевых процессов «Управление требованиями» — согласование требований, выдвигаемых к проекту разработки ПО заказчиком и разработчиком. Это соглашение с заказчиком является основой для планирования (группа ключевых процессов «Планирование проекта») проекта разработки и управления им (группа «Отслеживание хода проекта и контроль над ним»). Контроль над взаимоотношениями с заказчиком зависит от эффективности последующего процесса управления изменениями (группа «Управление конфигурацией ПО»).
      Цель группы ключевых процессов «Планирование проекта» — создание обоснованных планов разработки ПО и управления выполнением проекта разработки. Эти планы формируют необходимую основу для управления проектом (группа «Отслеживание хода проекта и контроль над ним»). Без реалистичных планов невозможно эффективно управлять проектом.
      Цель группы ключевых процессов «Отслеживание хода проекта и контроль над ним» — обеспечение адекватного обзора фактического выполнения проекта, позволяя руководству предпринимать эффективные меры при значительном отклонении хода проекта от планов разработки.
      Цель группы ключевых процессов «Управление производственным субподрядом» — выбор квалифицированных производственных субподрядчиков и эффективное управление ими. Она объединяет аспекты групп «Управление требованиями», «Планирование проекта» и «Отслеживание хода проекта и контроль над ним», касающиеся создания основного инструмента управления, описывает необходимую координацию с процессами из групп «Обеспечение качества ПО» и «Управление конфигурацией ПО» и применяет этот инструмент по отношению к субподрядчику.
      Цель группы ключевых процессов «Обеспечение качества ПО» заключается в том, чтобы дать руководству адекватное представление о ходе процесса разработки и о создаваемых продуктах. Обеспечение качества ПО является неотъемлемой частью большинства процессов, связанных с инженерией разработки и управлением ею.
      Цель группы ключевых процессов «Управление конфигурацией ПО» — обеспечение целостности продуктов проекта разработки ПО в течение всего жизненного цикла проекта. Управление конфигурацией ПО является неотъемлемой частью большинства процессов, связанных с инженерией разработки и управлением ею.
      Группы ключевых процессов уровня 3 связаны с вопросами, касающимися как отдельного проекта, так и организации в целом, поскольку организация внедряет инфраструктуру, устанавливающую эффективные процессы разработки ПО и управления для всех проектов. Ниже приводятся описания всех групп ключевых процессов уровня 3.
      Цель группы ключевых процессов «Координация производственного процесса организации» — установление организационной сферы ответственности за выполнение мероприятий, совершенствующих общие производственные возможности организации. Основным результатом работ этой группы является набор основных средств производственного процесса, описанных в группе ключевых процессов «Определение производственного процесса организации». Эти основные средства затем используются в проектах разработки (группа «Интегрированное управление разработкой ПО»).