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

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

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

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

Обзор

Модель зрелости возможностей изначально разрабатывалась как инструмент для объективной оценки возможностей государственных подрядчиков. процессы реализовать контрактный программный проект. Модель основана на структуре зрелости процессов, впервые описанной в Программное обеспечение IEEE[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]

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

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

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

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

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

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

Структура

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

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

Уровни

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

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

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

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

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

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

Критика

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

Структура программного процесса

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

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

Смотрите также

Рекомендации

  1. ^ Найаб, Н. (27 апреля 2010 г.). «Разница между CMMI и CMM». Bright Hub PM. Получено 2020-02-15.
  2. ^ Хамфри, В. С. (март 1988 г.). «Характеристика процесса разработки программного обеспечения: структура зрелости». Программное обеспечение IEEE. 5 (2): 73–79. Дои:10.1109/52.2014. ISSN  0740-7459. S2CID  1008347.
  3. ^ а б Paulk, Mark C .; Вебер, Карл V; Кертис, Билл; Криссис, Мэри Бет (февраль 1993 г.). «Модель зрелости возможностей для программного обеспечения (версия 1.1)» (PDF). Технический отчет. Питтсбург, Пенсильвания: Институт программной инженерии, Университет Карнеги-Меллона. CMU / SEI-93-TR-024 ESC-TR-93-177.
  4. ^ а б Маккей, Вивьен. «Что такое модель зрелости возможностей? (CMM) | Степень зрелости | Часто задаваемые вопросы». www.selectbs.com. Получено 2017-03-20.
  5. ^ Уайт, Сара К. (16.03.2018). «Что такое CMMI? Модель для оптимизации процессов разработки». ИТ-директор. Получено 2020-06-04.
  6. ^ Йордон, Э. (1989). 1989. Современный структурный анализ.. Нью-Йорк: Прентис Холл. ISBN  978-0135986240.
  7. ^ Вайнберг, Г.М. (1992). Качественное управление программным обеспечением: предвидение изменений. Vol. 1. Системное мышление. Нью-Йорк: Паб Дорсет Хаус. ISBN  978-0-932633-72-9.
  8. ^ DeMarco, T .; Листер, Т. (1997). Вальсируя с медведями: управление рисками программных проектов. Нью-Йорк: Паб Дорсет Хаус. ISBN  978-0-932633-60-6.
  9. ^ «CMMI-Six Sigma, их корни». Process Enhancement Partners, Inc. 2011-01-23. Получено 2018-05-11.
  10. ^ Нолан, Р. Л. (июль 1973 г.). «Управление компьютерным ресурсом: этапная гипотеза». Comm. ACM. 16 (7): 399–405. Дои:10.1145/362280.362284. S2CID  14053595.
  11. ^ «Модель зрелости способностей людей (P-CMM), версия 2.0». resources.sei.cmu.edu. Получено 2017-01-17.
  12. ^ Кросби, П. Б. (1979). Качество бесплатно. Нью-Йорк: Новая американская библиотека. ISBN  0-451-62247-2.
  13. ^ Хамфри, У.С. (Март 1988 г.). «Характеристика процесса разработки программного обеспечения: структура зрелости» (PDF). Программное обеспечение IEEE. 5 (2): 73–79. Дои:10.1109/52.2014. S2CID  1008347.
  14. ^ Хамфри, У.С. (1989). Управление программным процессом. Серия SEI в программной инженерии. Чтение, Масс .: Эддисон-Уэсли. ISBN  0-201-18095-2.
  15. ^ Paulk, Mark C .; Вебер, Карл V; Кертис, Билл; Криссис, Мэри Бет (1995). Модель зрелости возможностей: рекомендации по совершенствованию процесса разработки программного обеспечения. Серия SEI в программной инженерии. Чтение, Масс .: Эддисон-Уэсли. ISBN  0-201-54664-7.
  16. ^ Джуран (26 августа 2010 г.). Качество Джурана Hb 6E. McGraw-Hill Education (India) Pvt Limited. ISBN  9780071070898.
  17. ^ Натараджан, Р. (2015). Материалы Международной конференции по трансформации инженерного образования. Springer.
  18. ^ Приложение SDLC штата Мичиган по ШМ Свидетельствует об использовании текста в 2001 году, поэтому он не мог появиться отсюда.
  19. ^ «Тенденции внедрения CMMI - отчет за середину 2019 года». Институт CMMI. 2019-10-21.
  20. ^ Фишман, Чарльз (1996-12-31). "Они пишут правильный материал". Быстрая Компания. Получено 2020-02-15.

внешняя ссылка