Модель зрелости возможностей

Модель зрелости возможностей ( CMM ) — модель развития, созданная в 1986 году после изучения данных, собранных от организаций, заключивших контракт с Министерством обороны США , которое финансировало исследование. Термин «зрелость» относится к степени формальности и оптимизации процессов, от специальных практик до формально определенных шагов, до управляемых показателей результатов и активной оптимизации процессов.

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

В 2006 году Институт программной инженерии Университета Карнеги-Меллона разработал « Интеграционную модель зрелости возможностей» , которая в значительной степени заменила CMM и устраняет некоторые ее недостатки. ^[1]

Обзор

Модель зрелости возможностей изначально была разработана как инструмент для объективной оценки способности процессов государственных подрядчиков реализовать проект программного обеспечения по контракту. Модель основана на структуре зрелости процессов, впервые описанной в IEEE Software. ^[2] и позже в книге Управление процессом разработки программного обеспечения» Уоттса Хамфри « 1989 года . Позже он был опубликован в виде статьи в 1993 году. ^[3]и как книга тех же авторов в 1994 году. ^[4]

Хотя эта модель пришла из области разработки программного обеспечения , она также используется в качестве модели для помощи в бизнес-процессах в целом, а также широко используется во всем мире в государственных учреждениях, торговле и промышленности. ^[5]^[6]

История

Предварительная потребность в программных процессах

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

В результате рост сопровождался проблемами роста: провалы проектов были обычным явлением, область компьютерных наук все еще находилась в зачаточном состоянии, а амбиции по масштабу и сложности проектов превышали возможности рынка по поставке адекватных продуктов в рамках запланированного бюджета. Такие люди, как Эдвард Юрдон , ^[7] Ларри Константин , Джеральд Вайнберг , ^[8] Том ДеМарко , ^[9] а Дэвид Парнас начал публиковать статьи и книги с результатами исследований, пытаясь повысить профессионализм процессов разработки программного обеспечения. ^[5]^[10]

В 1980-х годах несколько военных проектов США с участием субподрядчиков программного обеспечения превысили бюджет и были завершены намного позже запланированного, если вообще были завершены. Пытаясь определить, почему это происходит, ВВС США профинансировали исследование в Институте программной инженерии (SEI).

Предшественник

Первое применение модели поэтапной зрелости к ИТ было не CMU/SEI, а Ричардом Л. Ноланом , который в 1973 году опубликовал модель стадий роста для ИТ-организаций. ^[11]

Уоттс Хамфри начал разрабатывать концепции зрелости процессов на поздних этапах своей 27-летней карьеры в IBM. ^[12]

Разработка в Институте программной инженерии

Активная разработка модели Институтом программной инженерии Министерства обороны США (SEI) началась в 1986 году, когда Хамфри присоединился к Институту программной инженерии, расположенному при Университете Карнеги-Меллона в Питтсбурге, штат Пенсильвания после ухода из IBM . По запросу ВВС США он начал формализовать свою структуру зрелости процессов, чтобы помочь Министерству обороны США оценить возможности подрядчиков по программному обеспечению в рамках заключения контрактов.

Результатом исследования ВВС стала модель, которую военные могли использовать в качестве объективной оценки зрелости технологических возможностей субподрядчиков программного обеспечения. Хамфри основал эту структуру на более ранней Сетке зрелости управления качеством, разработанной Филипом Б. Кросби в его книге «Качество бесплатно». ^[13] Подход Хамфри отличался своим уникальным пониманием того, что организации развивают свои процессы поэтапно, основываясь на решении процессных проблем в определенном порядке. Хамфри основывал свой подход на поэтапном развитии системы практик разработки программного обеспечения внутри организации, а не на независимом измерении зрелости каждого отдельного процесса разработки. Таким образом, CMM используется различными организациями в качестве общего и мощного инструмента для понимания и последующего улучшения общей производительности бизнес-процессов.

Модель зрелости возможностей (CMM) Уоттса Хамфри была опубликована в 1988 году. ^[14] и в виде книги в 1989 году «Управление процессом разработки программного обеспечения» . ^[15]

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

Полное представление модели зрелости возможностей как набора определенных областей процессов и практик на каждом из пяти уровней зрелости было начато в 1991 году, а версия 1.1 была опубликована в июле 1993 года. ^[3]CMM был издан в виде книги. ^[4] в 1994 году теми же авторами Марком К. Полком, Чарльзом В. Вебером, Биллом Кертисом и Мэри Бет Криссис.

Интеграция модели зрелости возможностей

Применение модели CMM при разработке программного обеспечения иногда было проблематичным. Применение нескольких моделей, которые не интегрированы внутри и внутри организации, может оказаться дорогостоящим для обучения, оценки и мероприятий по улучшению. Проект интеграции модели зрелости возможностей (CMMI) был сформирован для решения проблемы использования нескольких моделей для процессов разработки программного обеспечения. Таким образом, модель CMMI заменила модель CMM, хотя модель CMM продолжает оставаться общей теоретической моделью возможностей процесса, используемой в общественное достояние. ^[16]^{[ нужна ссылка ]}^[17]

В 2016 году ответственность за CMMI была передана Ассоциации аудита и контроля информационных систем (ISACA). Впоследствии ISACA выпустила CMMI v2.0 в 2021 году. В 2023 году она снова была обновлена до CMMI v3.0. Теперь CMMI уделяет больше внимания архитектуре процесса, которая обычно реализуется в виде диаграммы процесса. Копии CMMI теперь доступны только по подписке.

Адаптирован к другим процессам

Первоначально CMM был задуман как инструмент для оценки способности государственных подрядчиков выполнить проект программного обеспечения по контракту. Хотя она пришла из области разработки программного обеспечения, она может широко применяться, применялась и продолжает широко применяться в качестве общей модели зрелости процессов (например, процессов управления ИТ-услугами ) в ИС/ИТ (и других) организациях.

Модельные темы

Модели зрелости

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

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

Структура

Модель включает в себя пять аспектов:

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

Уровни

В континууме модели определены пять уровней, и, согласно SEI: «Считается, что предсказуемость, эффективность и контроль над программными процессами организации улучшаются по мере продвижения организации вверх по этим пяти уровням. Хотя эмпирические данные и не являются строгими, эмпирические данные на сегодняшний день подтверждает это убеждение». ^[18]

Начальный (хаотичный, специальный, индивидуальный героический) — отправная точка для использования нового или недокументированного повторного процесса.
Повторяемость – процесс, по крайней мере, достаточно документирован, чтобы можно было попытаться повторить одни и те же шаги.
Определен – процесс определен/подтвержден как стандартный бизнес-процесс.
Способен – процесс количественно управляется в соответствии с согласованными метриками.
Эффективность – управление процессами включает целенаправленную оптимизацию/улучшение процессов.

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

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

Уровень 1 – Начальный: Для процессов на этом уровне характерно то, что они (как правило) недокументированы и находятся в состоянии динамических изменений, которые имеют тенденцию управляться в произвольной , неконтролируемой и реактивной манере пользователями или событиями. Это создает хаотичную или нестабильную среду для процессов. (Пример – хирург проводит новую операцию небольшое количество раз – степень отрицательного результата неизвестна).

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

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

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

Уровень 5 – Оптимизация (Эффективность): Характерной чертой процессов на этом уровне является то, что основное внимание уделяется постоянному улучшению производительности процессов посредством как постепенных, так и инновационных технологических изменений/улучшений. На уровне зрелости 5 процессы направлены на устранение статистических распространенных причин отклонений процесса и изменение процесса (например, смещение среднего значения производительности процесса) для улучшения производительности процесса. Это будет осуществляться одновременно с поддержанием вероятности достижения установленных количественных целей улучшения процессов.

В период с 2008 по 2019 год около 12% проведенных оценок находились на уровнях зрелости 4 и 5. ^[19]^[20]

Критика

Первоначально модель предназначалась для оценки способности государственных подрядчиков выполнить проект программного обеспечения. Он использовался и может подойти для этой цели, но критики ^{[ ВОЗ? ]} отметил, что зрелость процесса в соответствии с CMM не обязательно является обязательной для успешной разработки программного обеспечения.

Структура процесса разработки программного обеспечения

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

Тип	Описание
Политика	Описывает содержание политики и цели КПД, рекомендованные ключевыми областями процессов.
Стандартный	Описывает рекомендуемое содержание избранных рабочих продуктов, описанных в ключевых областях процесса.
Процесс	Описывает информационное содержание процесса, рекомендованное ключевыми областями процесса. Они уточняются в контрольные списки для: Роли, критерии входа, входы, действия, результаты, критерии выхода, обзоры и аудиты, управляемые и контролируемые рабочие продукты, измерения, документированные процедуры, обучение и инструменты.
Процедура	Описывает рекомендуемое содержание документированных процедур, описанных в ключевых областях процесса.
Уровень преодолен	Предоставляет обзор всего уровня зрелости. Далее они уточняются в контрольные списки для: Цели, задачи, политики и стандарты ключевых областей процессов; описания процессов; процедуры; обучение; инструменты; обзоры и аудиты; продукты работы; измерения

См. также

Ссылки

^ Наяб, Н. (27 апреля 2010 г.). «Разница между CMMI и CMM» . Яркий Хаб ПМ . Проверено 15 февраля 2020 г.
^ Хамфри, WS (март 1988 г.). «Характеристика процесса разработки программного обеспечения: структура зрелости». Программное обеспечение IEEE . 5 (2): 73–79. дои : 10.1109/52.2014 . ISSN 0740-7459 . S2CID 1008347 .
^ Перейти обратно: ^а ^б Марк К. Полк; Билл Кертис; Мэри Бет Криссис; Чарльз В. Вебер (июль 1993 г.). «Модель зрелости возможностей, версия 1.1». Программное обеспечение IEEE . 10 (4). IEEE : 18–27. дои : 10.1109/52.219617 .
^ Перейти обратно: ^а ^б Марк К. Полк; Чарльз В. Вебер; Билл Кертис; Мэри Бет Криссис (1 января 1994 г.). Модель зрелости возможностей: рекомендации по улучшению процесса разработки программного обеспечения (1-е изд.). Аддисон-Уэсли Профессионал . ISBN 978-0-201-54664-4 .
^ Перейти обратно: ^а ^б Маккей, Вивьен. «Что такое модель зрелости возможностей? (CMM) | Зрелость процесса | Часто задаваемые вопросы» . www.selectbs.com . Проверено 20 марта 2017 г.
^ Уайт, Сара К. (16 марта 2018 г.). «Что такое CMMI? Модель оптимизации процессов разработки» . ИТ-директор . Проверено 4 июня 2020 г.
^ Юрдон, Э. (1989). 1989. Современный структурный анализ . Нью-Йорк: Прентис Холл. ISBN 978-0135986240 .
^ Вайнберг, генеральный директор (1992). Управление качеством программного обеспечения: ожидание перемен. Том. 1: Системное мышление . Нью-Йорк: Паб Dorset House. ISBN 978-0-932633-72-9 .
^ ДеМарко, Т.; Листер, Т. (1997). Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения . Нью-Йорк: Паб Dorset House. ISBN 978-0-932633-60-6 .
^ «CMMI-Шесть Сигм, их корни» . Партнеры по улучшению процессов, Inc. 23 января 2011 г. Проверено 11 мая 2018 г.
^ Нолан, Р.Л. (июль 1973 г.). «Управление компьютерным ресурсом: этапная гипотеза» . Комм. АКМ . 16 (7): 399–405. дои : 10.1145/362280.362284 . S2CID 14053595 .
^ «Модель зрелости способностей персонала (P-CMM), версия 2.0» . resources.sei.cmu.edu . Проверено 17 января 2017 г.
^ Кросби, ПБ (1979). Качество бесплатно . Нью-Йорк: Новая американская библиотека . ISBN 0-451-62247-2 .
^ Хамфри, WS (март 1988 г.). «Характеристика процесса разработки программного обеспечения: структура зрелости» (PDF) . Программное обеспечение IEEE . 5 (2): 73–79. дои : 10.1109/52.2014 . S2CID 1008347 .
^ Хамфри, WS (1989). Управление процессом разработки программного обеспечения . Серия SEI по разработке программного обеспечения. Ридинг, Массачусетс: Аддисон-Уэсли . ISBN 0-201-18095-2 .
^ Джуран (26 августа 2010 г.). Качество Джурана Hb 6E . McGraw-Hill Education (India) Pvt Limited. ISBN 9780071070898 .
^ Натараджан, Р. (2015). Материалы международной конференции «Трансформации в инженерном образовании» . Спрингер.
^ Приложение SDLC штата Мичиган по ШМ подтверждает использование текста в 2001 году, поэтому он не мог быть взят отсюда.
^ «Тенденции внедрения CMMI — полугодовой отчет за 2019 год» . Институт CMMI . 21.10.2019.
^ Фишман, Чарльз (31 декабря 1996 г.). «Они пишут правильные вещи» . Компания Фаст . Проверено 15 февраля 2020 г.

Внешние ссылки

[1] Наяб, Н. (27 апреля 2010 г.). «Разница между CMMI и CMM» . Яркий Хаб ПМ . Проверено 15 февраля 2020 г.

[2] Хамфри, WS (март 1988 г.). «Характеристика процесса разработки программного обеспечения: структура зрелости». Программное обеспечение IEEE . 5 (2): 73–79. дои : 10.1109/52.2014 . ISSN 0740-7459 . S2CID 1008347 .

[sei93cmm-3] Перейти обратно: ^а ^б Марк К. Полк; Билл Кертис; Мэри Бет Криссис; Чарльз В. Вебер (июль 1993 г.). «Модель зрелости возможностей, версия 1.1». Программное обеспечение IEEE . 10 (4). IEEE : 18–27. дои : 10.1109/52.219617 .

[sei94cmmBook-4] Перейти обратно: ^а ^б Марк К. Полк; Чарльз В. Вебер; Билл Кертис; Мэри Бет Криссис (1 января 1994 г.). Модель зрелости возможностей: рекомендации по улучшению процесса разработки программного обеспечения (1-е изд.). Аддисон-Уэсли Профессионал . ISBN 978-0-201-54664-4 .

[McKay-5] Перейти обратно: ^а ^б Маккей, Вивьен. «Что такое модель зрелости возможностей? (CMM) | Зрелость процесса | Часто задаваемые вопросы» . www.selectbs.com . Проверено 20 марта 2017 г.

[6] Уайт, Сара К. (16 марта 2018 г.). «Что такое CMMI? Модель оптимизации процессов разработки» . ИТ-директор . Проверено 4 июня 2020 г.

[yourdon89msa-7] Юрдон, Э. (1989). 1989. Современный структурный анализ . Нью-Йорк: Прентис Холл. ISBN 978-0135986240 .

[weinberg92qsm-8] Вайнберг, генеральный директор (1992). Управление качеством программного обеспечения: ожидание перемен. Том. 1: Системное мышление . Нью-Йорк: Паб Dorset House. ISBN 978-0-932633-72-9 .

[demarcolister97wwb-9] ДеМарко, Т.; Листер, Т. (1997). Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения . Нью-Йорк: Паб Dorset House. ISBN 978-0-932633-60-6 .

[10] «CMMI-Шесть Сигм, их корни» . Партнеры по улучшению процессов, Inc. 23 января 2011 г. Проверено 11 мая 2018 г.

[11] Нолан, Р.Л. (июль 1973 г.). «Управление компьютерным ресурсом: этапная гипотеза» . Комм. АКМ . 16 (7): 399–405. дои : 10.1145/362280.362284 . S2CID 14053595 .

[12] «Модель зрелости способностей персонала (P-CMM), версия 2.0» . resources.sei.cmu.edu . Проверено 17 января 2017 г.

[crosby79qif-13] Кросби, ПБ (1979). Качество бесплатно . Нью-Йорк: Новая американская библиотека . ISBN 0-451-62247-2 .

[14] Хамфри, WS (март 1988 г.). «Характеристика процесса разработки программного обеспечения: структура зрелости» (PDF) . Программное обеспечение IEEE . 5 (2): 73–79. дои : 10.1109/52.2014 . S2CID 1008347 .

[watts89msp-15] Хамфри, WS (1989). Управление процессом разработки программного обеспечения . Серия SEI по разработке программного обеспечения. Ридинг, Массачусетс: Аддисон-Уэсли . ISBN 0-201-18095-2 .

[16] Джуран (26 августа 2010 г.). Качество Джурана Hb 6E . McGraw-Hill Education (India) Pvt Limited. ISBN 9780071070898 .

[17] Натараджан, Р. (2015). Материалы международной конференции «Трансформации в инженерном образовании» . Спрингер.

[18] Приложение SDLC штата Мичиган по ШМ подтверждает использование текста в 2001 году, поэтому он не мог быть взят отсюда.

[19] «Тенденции внедрения CMMI — полугодовой отчет за 2019 год» . Институт CMMI . 21.10.2019.

[20] Фишман, Чарльз (31 декабря 1996 г.). «Они пишут правильные вещи» . Компания Фаст . Проверено 15 февраля 2020 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]