Модель зрелости возможностей ( CMM ) — модель развития, созданная в 1986 году после изучения данных, собранных от организаций, заключивших контракт с Министерством обороны США , которое финансировало исследование. Термин «зрелость» относится к степени формальности и оптимизации процессов, от специальных практик до формально определенных шагов, до управляемых показателей результатов и активной оптимизации процессов.
Целью модели является улучшение существующих процессов разработки программного обеспечения , но ее также можно применять и к другим процессам.
В 2006 году Институт программной инженерии Университета Карнеги-Меллона разработал интеграционную модель зрелости возможностей , которая в значительной степени заменила CMM и устраняет некоторые ее недостатки. [1]
Модель зрелости возможностей изначально была разработана как инструмент для объективной оценки способности процессов государственных подрядчиков реализовать проект программного обеспечения по контракту. Модель основана на концепции зрелости процесса, впервые описанной в IEEE Software [2] , а затем в книге Уоттса Хамфри «Управление процессом разработки программного обеспечения» 1989 года . Позже он был опубликован в отчете в 1993 году [3] и в виде книги тех же авторов в 1995 году.
Хотя эта модель пришла из области разработки программного обеспечения , она также используется в качестве модели для помощи в бизнес-процессах в целом, а также широко используется во всем мире в государственных учреждениях, торговле и промышленности. [4] [5]
В 1980-е годы использование компьютеров стало более распространенным, более гибким и менее дорогостоящим. Организации начали внедрять компьютеризированные информационные системы, и спрос на разработку программного обеспечения значительно вырос. Многие процессы разработки программного обеспечения находились в зачаточном состоянии, и было определено лишь несколько стандартных или « лучших практик » подходов.
В результате рост сопровождался проблемами роста: провалы проектов были обычным явлением, область компьютерных наук все еще находилась в зачаточном состоянии, а амбиции по масштабу и сложности проектов превышали возможности рынка по поставке адекватных продуктов в рамках запланированного бюджета. Такие люди, как Эдвард Юрдон , [6] Ларри Константин , Джеральд Вайнберг , [7] Том ДеМарко , [8] и Дэвид Парнас начали публиковать статьи и книги с результатами исследований в попытке профессионализировать процессы разработки программного обеспечения. [4] [9]
В 1980-е годы несколько военных проектов США с участием субподрядчиков программного обеспечения превысили бюджет и были завершены намного позже запланированного, если вообще были завершены. Пытаясь выяснить, почему это происходит, ВВС США профинансировали исследование в Институте программной инженерии (SEI).
Первое применение модели поэтапной зрелости к ИТ было не CMU/SEI, а скорее Ричардом Л. Ноланом , который в 1973 году опубликовал модель стадий роста для ИТ-организаций. [10]
Уоттс Хамфри начал разрабатывать концепции зрелости процессов на поздних этапах своей 27-летней карьеры в IBM. [11]
Активная разработка модели Институтом программной инженерии Министерства обороны США (SEI) началась в 1986 году, когда Хамфри после ухода из IBM присоединился к Институту программной инженерии , расположенному при Университете Карнеги-Меллон в Питтсбурге, штат Пенсильвания . По запросу ВВС США он начал формализовать свою структуру зрелости процессов, чтобы помочь Министерству обороны США оценить возможности подрядчиков по программному обеспечению в рамках заключения контрактов.
Результатом исследования ВВС стала модель, которую военные могли использовать в качестве объективной оценки зрелости технологических возможностей субподрядчиков программного обеспечения. Хамфри основал эту структуру на более ранней Сетке зрелости управления качеством , разработанной Филипом Б. Кросби в его книге «Качество бесплатно». [12] Подход Хамфри отличался своим уникальным пониманием того, что организации развивают свои процессы поэтапно, основываясь на решении процессных проблем в определенном порядке. Хамфри основывал свой подход на поэтапном развитии системы практик разработки программного обеспечения внутри организации, а не на независимом измерении зрелости каждого отдельного процесса разработки. Таким образом, CMM используется различными организациями как общий и мощный инструмент для понимания и последующего улучшения общей производительности бизнес-процессов.
Модель зрелости возможностей (CMM) Уоттса Хамфри была опубликована в 1988 году [13] и в виде книги в 1989 году в журнале «Управление программным процессом» . [14]
Первоначально организации оценивались с помощью опросника зрелости процессов и метода оценки возможностей программного обеспечения, разработанного Хамфри и его коллегами из Института программной инженерии.
Полное представление модели зрелости возможностей как набора определенных областей процессов и практик на каждом из пяти уровней зрелости было начато в 1991 году, а версия 1.1 была завершена в январе 1993 года. [3] CMM был опубликован в виде книги [15 ] ] в 1995 году ее основными авторами Марком К. Полком, Чарльзом В. Вебером, Биллом Кертисом и Мэри Бет Криссис. Соединённые Штаты Америки Нью-Йорк, США.
Применение модели CMM при разработке программного обеспечения иногда было проблематичным. Применение нескольких моделей, которые не интегрированы внутри и внутри организации, может оказаться дорогостоящим для обучения, оценки и мероприятий по улучшению. Проект интеграции модели зрелости возможностей (CMMI) был сформирован для решения проблемы использования нескольких моделей для процессов разработки программного обеспечения. Таким образом, модель CMMI заменила модель CMM, хотя модель CMM продолжает оставаться общей теоретической моделью возможностей процесса, используемой в общественное достояние. [16] [ нужна ссылка ] [17]
В 2016 году ответственность за CMMI была передана Ассоциации аудита и контроля информационных систем (ISACA). Впоследствии ISACA выпустила CMMI v2.0 в 2021 году. В 2023 году она снова была обновлена до CMMI v3.0. Теперь CMMI уделяет больше внимания архитектуре процесса, которая обычно реализуется в виде диаграммы процесса. Копии CMMI теперь доступны только по подписке.
Первоначально CMM был задуман как инструмент для оценки способности государственных подрядчиков выполнить проект программного обеспечения по контракту. Хотя она пришла из области разработки программного обеспечения, она может широко применяться, применялась и продолжает широко применяться в качестве общей модели зрелости процессов ( например, процессов управления ИТ-услугами ) в ИС/ИТ (и других) организациях.
Модель зрелости можно рассматривать как набор структурированных уровней, которые описывают, насколько хорошо поведение, практика и процессы организации могут надежно и устойчиво приносить требуемые результаты.
Модель зрелости может использоваться как эталон для сравнения и как вспомогательное средство для понимания – например, для сравнительной оценки различных организаций, где есть что-то общее, что можно использовать в качестве основы для сравнения. Например, в случае CMM основой для сравнения будут процессы разработки программного обеспечения организаций.
Модель включает в себя пять аспектов:
В континууме модели определены пять уровней, и, согласно SEI: «Считается, что предсказуемость, эффективность и контроль над программными процессами организации улучшаются по мере продвижения организации вверх по этим пяти уровням. Хотя эмпирические данные и не являются строгими, эмпирические данные на сегодняшний день подтверждает это убеждение». [18]
Внутри каждого из этих уровней зрелости есть ключевые области процессов, которые характеризуют этот уровень, и для каждой такой области существует пять факторов: цели, обязательства, способности, измерение и проверка. Они не обязательно являются уникальными для CMM, поскольку представляют собой этапы, которые организации должны пройти на пути к зрелости.
Модель обеспечивает теоретический континуум, в рамках которого зрелость процесса может постепенно развиваться от одного уровня к другому. Пропуск уровней не допускается/невозможен.
В период с 2008 по 2019 год около 12% проведенных оценок находились на уровнях зрелости 4 и 5. [19] [20]
Первоначально модель предназначалась для оценки способности государственных подрядчиков выполнить проект программного обеспечения. Он использовался и может подойти для этой цели, но критики [ кто? ] отметил, что зрелость процесса в соответствии с CMM не обязательно является обязательной для успешной разработки программного обеспечения.
Документированная структура процессов разработки программного обеспечения предназначена для тех, кто хочет оценить соответствие организации или проекта ключевым областям процессов. Для каждого уровня зрелости существует пять типов контрольных списков: