Модель зрелости возможностей ( CMM ) - это модель развития, созданная в 1986 году после изучения данных, собранных организациями, заключившими контракт с Министерством обороны США , которое финансировало исследование. Термин «зрелость» относится к степени формальности и оптимизации процессов, от специальных практик до формально определенных шагов, показателей управляемых результатов и активной оптимизации процессов.
Цель модели - улучшить существующие процессы разработки программного обеспечения , но ее также можно применить к другим процессам.
В 2006 году Институт программной инженерии при Университете Карнеги-Меллона разработал интеграцию модели зрелости возможностей , которая в значительной степени заменила CMM и устраняет некоторые ее недостатки. [1]
Обзор
Capability Maturity Model первоначально был разработан в качестве инструмента для объективной оценки способности правительственных подрядчиков процессов для реализации сокращенного программного проекта. Модель основана на фреймворке зрелости процесса впервые была описана в IEEE Software [2] , а затем, в 1989 году книге Управление процессом программного обеспечения по Watts Humphrey . Позже он был опубликован в отчете в 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 году была опубликована в виде книги Managing the Software Process . [14]
Первоначально для оценки организаций использовались анкеты зрелости процессов и метод оценки возможностей программного обеспечения, разработанный Хамфри и его коллегами из Института программной инженерии.
Полное представление модели зрелости возможностей в виде набора определенных областей процессов и практик на каждом из пяти уровней зрелости было начато в 1991 году, а версия 1.1 была завершена в январе 1993 года. [3] CMM была опубликована в виде книги [15] ] в 1995 году его основными авторами Марком К. Полком, Чарльзом В. Вебером, Биллом Кертисом и Мэри Бет Криссис. Соединенные Штаты Америки Нью-Йорк, США.
Модель зрелости интеграции
Применение модели CMM в разработке программного обеспечения иногда было проблематичным. Применение нескольких моделей, которые не интегрированы внутри и внутри организации, может быть дорогостоящим при обучении, оценках и мероприятиях по улучшению. Проект интеграции модели зрелости возможностей (CMMI) был сформирован для решения проблемы использования нескольких моделей для процессов разработки программного обеспечения, таким образом, модель CMMI заменила модель CMM, хотя модель CMM продолжает оставаться общей теоретической моделью возможностей процесса, используемой в общественное достояние. [16] [ необходима ссылка ] [17]
Адаптирован к другим процессам
Изначально CMM предназначалась как инструмент для оценки способности государственных подрядчиков выполнять контрактный проект программного обеспечения. Хотя он исходит из области разработки программного обеспечения, он может быть, был и продолжает широко применяться в качестве общей модели зрелости процесса (например, процессов управления ИТ-услугами ) в ИТ / ИТ (и других) организациях.
Модельные темы
Модели зрелости
Модель зрелости можно рассматривать как набор структурированных уровней, которые описывают, насколько хорошо поведение, практики и процессы организации могут надежно и устойчиво обеспечивать требуемые результаты.
Модель зрелости может использоваться в качестве эталона для сравнения и помощи в понимании - например, для сравнительной оценки различных организаций, в которых есть что-то общее, что можно использовать в качестве основы для сравнения. В случае CMM, например, основой для сравнения будут процессы разработки программного обеспечения организаций.
Состав
Модель включает пять аспектов:
- Уровни зрелости: 5-уровневый континуум зрелости процессов, где самый верхний (5-й) уровень является условно идеальным состоянием, при котором процессы будут систематически управляться путем сочетания оптимизации процессов и непрерывного улучшения процессов.
- Ключевые области процесса: область ключевого процесса определяет группу связанных действий, которые при совместном выполнении позволяют достичь ряда важных целей.
- Цели: цели ключевой области процесса резюмируют состояния, которые должны существовать для того, чтобы эта основная область процесса была реализована эффективным и длительным образом. Степень достижения целей является показателем того, какие возможности организация создала на этом уровне зрелости. Цели обозначают объем, границы и цель каждой ключевой области процесса.
- Общие черты: общие черты включают практики, которые реализуют и институционализируют ключевую область процесса. Существует пять типов общих характеристик: обязательство выполнять, способность выполнять, выполняемые действия, измерения и анализ, а также проверка выполнения.
- Ключевые практики: ключевые практики описывают элементы инфраструктуры и практики, которые наиболее эффективно способствуют реализации и институционализации области.
Уровни
В континууме модели определены пять уровней, и, согласно SEI: «Предполагается, что предсказуемость, эффективность и контроль программных процессов организации улучшаются по мере того, как организация поднимается на эти пять уровней. Хотя это и не является строгим, эмпирические данные на сегодняшний день поддерживает это убеждение ». [18]
- Начальный (хаотичный, случайный, индивидуальный героизм) - отправная точка для использования нового или недокументированного повторного процесса.
- Повторяемость - процесс, по крайней мере, достаточно документирован, чтобы можно было попытаться повторить те же шаги.
- Определен - процесс определен / подтвержден как стандартный бизнес-процесс
- Возможности - процесс количественно управляется в соответствии с согласованными показателями.
- Эффективность - управление процессами включает в себя целенаправленную оптимизацию / улучшение процесса.
Внутри каждого из этих уровней зрелости есть ключевые области процесса, которые характеризуют этот уровень, и для каждой такой области есть пять факторов: цели, приверженность, способность, измерение и проверка. Они не обязательно являются уникальными для CMM, представляя - как они это делают - этапы, которые организации должны пройти на пути к зрелости.
Модель обеспечивает теоретический континуум, в соответствии с которым зрелость процесса может постепенно развиваться от одного уровня к другому. Пропуск уровней недопустим / невозможен.
- Уровень 1 - Начальный
- Характерной чертой процессов на этом уровне является то, что они (как правило) недокументированы и находятся в состоянии динамического изменения, которое имеет тенденцию быть управляемым пользователем или событиями произвольно , неконтролируемым и реактивным образом. Это создает хаотичную или нестабильную среду для процессов. (Пример - хирург, выполняющий новую операцию небольшое количество раз - уровни отрицательного результата неизвестны).
- Уровень 2 - Повторяемый
- Для этого уровня зрелости характерно то, что некоторые процессы воспроизводимы, возможно, с устойчивыми результатами. Маловероятно, что процессная дисциплина будет жесткой, но там, где она существует, она может помочь обеспечить поддержание существующих процессов во время стресса.
- Уровень 3 - Определенный
- Характерной чертой процессов на этом уровне является наличие наборов определенных и задокументированных стандартных процессов, установленных и подлежащих некоторой степени улучшения с течением времени. Эти стандартные процессы действуют. Возможно, процессы не использовались систематически или неоднократно - этого было достаточно для того, чтобы пользователи стали компетентными или чтобы процесс прошел валидацию в ряде ситуаций. Это можно считать этапом развития - при использовании в более широком диапазоне условий и развитии пользовательской компетентности процесс может развиться до следующего уровня зрелости.
- Уровень 4 - управляемый (способный)
- Для процессов на этом уровне характерно то, что с помощью метрик процесса эффективное достижение целей процесса может быть подтверждено в целом ряде рабочих условий. Пригодность процесса в различных средах была проверена, а процесс доработан и адаптирован. Пользователи процесса испытали процесс в нескольких и разнообразных условиях и могут продемонстрировать свою компетентность. Зрелость процесса позволяет адаптироваться к конкретным проектам без ощутимых потерь качества или отклонений от спецификаций. Возможности процесса устанавливаются с этого уровня. (Пример - хирург, проводивший операцию сотни раз с уровнем отрицательного результата, близким к нулю).
- Уровень 5 - Оптимизация (эффективный)
- Характерной чертой процессов на этом уровне является то, что основное внимание уделяется постоянному повышению производительности процесса за счет как постепенных, так и инновационных технологических изменений / улучшений. На уровне зрелости 5 процессы связаны с устранением статистических общих причин вариаций процесса и изменением процесса (например, смещением среднего значения производительности процесса) для повышения производительности процесса. Это будет происходить одновременно с поддержанием вероятности достижения установленных количественных целей улучшения процесса.
В период с 2008 по 2019 год около 12% оценок приходилось на уровни зрелости 4 и 5. [19] [20]
Критика
Изначально модель предназначалась для оценки способности государственных подрядчиков выполнять программный проект. Он использовался и может подходить для этой цели, но критики [ кто? ] отметил, что зрелость процессов в соответствии с CMM не обязательно является обязательной для успешной разработки программного обеспечения.
Фреймворк программных процессов
Задокументированная структура программного процесса предназначена для того, чтобы помочь тем, кто хочет оценить соответствие организации или проекта ключевым областям процессов. Для каждого уровня зрелости существует пять типов контрольных списков:
Тип Описание Политика Описывает содержание политики и цели KPA, рекомендованные ключевыми областями процессов. Стандарт Описывает рекомендуемое содержание избранных рабочих продуктов, описанных в ключевых областях процесса. Процесс Описывает информационное наполнение процесса, рекомендованное ключевыми областями процесса. Они уточнены в контрольных списках для: - Роли, критерии входа, входы, действия, выходы, критерии выхода, обзоры и аудиты, рабочие продукты, управляемые и контролируемые, измерения, документированные процедуры, обучение и инструменты
Процедура Описывает рекомендуемое содержание документированных процедур, описанных в ключевых областях процесса. Обзор уровня Предоставляет обзор всего уровня зрелости. Они далее уточняются в контрольных списках для: - Цели, задачи, политика и стандарты ключевых областей процесса; описания процессов; процедуры; обучение; инструменты; обзоры и аудиты; рабочие продукты; измерения
Смотрите также
- Модель незрелости возможностей
- Модель зрелости интеграции
- Модель зрелости способностей людей
- Модель зрелости тестирования
Рекомендации
- ^ Nayab, Н. (2010-04-27). «Разница между CMMI и CMM» . Bright Hub PM . Проверено 15 февраля 2020 .
- ^ Хамфри, WS (март 1988 г.). «Характеристика процесса разработки программного обеспечения: структура зрелости». Программное обеспечение IEEE . 5 (2): 73–79. DOI : 10.1109 / 52.2014 . ISSN 0740-7459 . S2CID 1008347 .
- ^ а б Paulk, Mark C .; Вебер, Карл V; Кертис, Билл ; Криссис, Мэри Бет (февраль 1993 г.). «Модель зрелости возможностей программного обеспечения (версия 1.1)» (PDF) . Технический отчет . Питтсбург, Пенсильвания: Институт программной инженерии, Университет Карнеги-Меллона. CMU / SEI-93-TR-024 ESC-TR-93-177.
- ^ а б Маккей, Вивьен. «Что такое модель зрелости возможностей? (CMM) | Степень зрелости | Часто задаваемые вопросы» . www.selectbs.com . Проверено 20 марта 2017 .
- ^ Уайт, Сара К. (16.03.2018). «Что такое CMMI? Модель для оптимизации процессов разработки» . ИТ-директор . Проверено 4 июня 2020 .
- ^ Йордон, Э. (1989). 1989. Современный структурный анализ . Нью-Йорк: Прентис-Холл. ISBN 978-0135986240.
- ^ Вайнберг, GM (1992). Качественное управление программным обеспечением: прогнозирование изменений. Vol. 1: Системное мышление . Нью-Йорк: паб Дорсет Хаус. ISBN 978-0-932633-72-9.
- ^ DeMarco, T .; Листер, Т. (1997). Вальсируя с медведями: управление рисками программных проектов . Нью-Йорк: паб Дорсет Хаус. ISBN 978-0-932633-60-6.
- ^ «CMMI-Six Sigma, их корни» . Процесс Enhancement Partners, Inc . 2011-01-23 . Проверено 11 мая 2018 .
- ^ Нолан, Р.Л. (июль 1973 г.). «Управление компьютерным ресурсом: этапная гипотеза». Comm. ACM . 16 (7): 399–405. DOI : 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. DOI : 10.1109 / 52.2014 . S2CID 1008347 .
- ^ Хамфри, WS (1989). Управление программным процессом . Серия SEI в программной инженерии. Ридинг, Массачусетс: Эддисон-Уэсли . ISBN 0-201-18095-2.
- ^ Paulk, Mark C .; Вебер, Карл V; Кертис, Билл ; Криссис, Мэри Бет (1995). Модель зрелости возможностей: рекомендации по совершенствованию процесса разработки программного обеспечения . Серия SEI в программной инженерии. Ридинг, Массачусетс: Эддисон-Уэсли . ISBN 0-201-54664-7.
- ^ Джуран (26 августа 2010 г.). Качество Джурана Hb 6E . McGraw-Hill Education (India) Pvt Limited. ISBN 9780071070898.
- ^ Натараджан, Р. (2015). Материалы Международной конференции «Трансформации в инженерном образовании» . Springer.
- ^ Приложение SDLC штата Мичиган о КИМ свидетельствует об использовании текста в 2001 году, поэтому он не мог появиться отсюда.
- ^ «Тенденции внедрения CMMI - отчет за середину 2019 года» . Институт CMMI . 2019-10-21.
- ^ Фишман, Чарльз (1996-12-31). «Они пишут правильный материал» . Быстрая компания . Проверено 15 февраля 2020 .
Внешние ссылки
- Институт CMMI
- Модель зрелости возможностей в Curlie
- Модели зрелости архитектуры в Open Group