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

• 1 Обзор
• 2 История
  • 2.1 Предыдущая потребность в процессах программного обеспечения
  • 2.2 Предшественник
  • 2.3 Разработка в Институте программной инженерии
  • 2.4 Интеграция модели зрелости возможностей
  • 2.5 Адаптировано к другие процессы
• 3 Темы моделей
  • 3.1 Модели зрелости
  • 3.2 Структура
  • 3.3 Уровни
  • 3.4 Критика
  • 3.5 Структура программных процессов
• 4 См. также
• 5 Ссылки
• 6 Внешние ссылки

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

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

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

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

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

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

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

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

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

Разработка в Software Инженерный институт

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

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

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

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

Полное представление модели зрелости возможностей в виде набора определенных областей процессов и практик на каждом из пяти уровней зрелости было начато в 1991 году, а версия 1.1 была завершена в январе 1993 года. CMM была опубликована как книга в 1995 году ее основными авторами, Марком К. Полком, Чарльзом В. Вебером, Биллом Кертисом и Мэри Бет Криссис. Соединенные Штаты Америки Нью-Йорк, США.

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

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

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

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

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

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

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

Структура

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

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

Уровни

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

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

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

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

Уровень 1 - Начальный

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

Уровень 2 - Повторяемый

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

Уровень 3 - Определен

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

Уровень 4 - Управляемый (способный)

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

Уровень 5 - Оптимизация (эффективный)

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

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

Критика

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

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

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

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

• Модель незрелости возможностей
• Интеграция модели зрелости способностей
• Модель зрелости способностей сотрудников
• Тестирование модели зрелости

Wikimedia Commons имеет СМИ, связанные с Интеграция модели зрелости возможностей.

• Институт CMMI
• Модель зрелости возможностей в Керли
• Модели зрелости архитектуры в The Open Group