stringtranslate.com

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

Модель зрелости возможностей ( 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]

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

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

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

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

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

Критика

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

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

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

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

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

  1. ^ Наяб, Н. (27 апреля 2010 г.). «Разница между CMMI и CMM». Яркий Хаб ПМ . Проверено 15 февраля 2020 г.
  2. ^ Хамфри, WS (март 1988 г.). «Характеристика процесса разработки программного обеспечения: рамки зрелости». Программное обеспечение IEEE . 5 (2): 73–79. дои : 10.1109/52.2014. ISSN  0740-7459. S2CID  1008347.
  3. ^ Аб Полк, Марк С.; Вебер, Карл V; Кертис, Билл ; Криссис, Мэри Бет (февраль 1993 г.). «Модель зрелости возможностей программного обеспечения (версия 1.1)» (PDF) . Технический отчет . Питтсбург, Пенсильвания: Институт разработки программного обеспечения Университета Карнеги-Меллон. CMU/SEI-93-TR-024 ESC-TR-93-177. Архивировано (PDF) из оригинала 3 января 2011 г.
  4. ^ Аб Маккей, Вивьен. «Что такое модель зрелости возможностей? (CMM) | Зрелость процесса | Часто задаваемые вопросы». www.selectbs.com . Проверено 20 марта 2017 г.
  5. ^ Уайт, Сара К. (16 марта 2018 г.). «Что такое CMMI? Модель оптимизации процессов разработки». ИТ-директор . Проверено 4 июня 2020 г.
  6. ^ Юрдон, Э. (1989). 1989. Современный структурный анализ . Нью-Йорк: Прентис Холл. ISBN 978-0135986240.
  7. ^ Вайнберг, GM (1992). Управление качеством программного обеспечения: предвидение изменений. Том. 1: Системное мышление . Нью-Йорк: Паб Dorset House. ISBN 978-0-932633-72-9.
  8. ^ ДеМарко, Т.; Листер, Т. (1997). Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения . Нью-Йорк: Паб Dorset House. ISBN 978-0-932633-60-6.
  9. ^ «CMMI-Шесть Сигм, их корни». Партнеры по улучшению процессов, Inc. 23 января 2011 г. Проверено 11 мая 2018 г.
  10. ^ Нолан, Р.Л. (июль 1973 г.). «Управление компьютерным ресурсом: гипотеза этапа». Комм. АКМ . 16 (7): 399–405. дои : 10.1145/362280.362284 . S2CID  14053595.
  11. ^ «Модель зрелости возможностей персонала (P-CMM), версия 2.0» . resources.sei.cmu.edu . Проверено 17 января 2017 г.
  12. ^ Кросби, ПБ (1979). Качество бесплатно . Нью-Йорк: Новая американская библиотека . ISBN 0-451-62247-2.
  13. ^ Хамфри, WS (март 1988 г.). «Характеристика процесса разработки программного обеспечения: структура зрелости» (PDF) . Программное обеспечение IEEE . 5 (2): 73–79. дои : 10.1109/52.2014. S2CID  1008347.
  14. ^ Хамфри, WS (1989). Управление процессом разработки программного обеспечения . Серия SEI по разработке программного обеспечения. Ридинг, Массачусетс: Аддисон-Уэсли . ISBN 0-201-18095-2.
  15. ^ Полк, Марк С.; Вебер, Карл V; Кертис, Билл ; Криссис, Мэри Бет (1995). Модель зрелости возможностей: рекомендации по улучшению процесса разработки программного обеспечения . Серия SEI по разработке программного обеспечения. Ридинг, Массачусетс: Аддисон-Уэсли . ISBN 0-201-54664-7.
  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 г.

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