Capability Maturity Model — модель зрелости возможностей (модель полноты потенциала) создания ПО : эволюционная модель развития способности компании разрабатывать программное обеспечение.

История

В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

Разработка такого обзора была вызвана запросом американского федерального правительства на предоставление метода оценки субподрядчиков для разработки ПО. Реальная же проблема состояла в неспособности управлять большими проектами. Во многих компаниях проекты выполнялись со значительным опозданием и с превышением запланированного бюджета. Необходимо было найти решение данной проблемы.

В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, вследствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в которой принимали участие около 200 специалистов в области ПО, и членами общества разработчиков.

Уровни

1. Начальный. Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу, и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве.
2. Повторяемый. В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. В середине 1999 года лишь 20 % организаций имели 2-й уровень или выше.
3. Установленный. Имеют определённый, документированный и установленный процесс работы, не зависящий от отдельных личностей. Вводятся согласованные профессиональные стандарты , а разработчики их выполняют. Такие организации в состоянии достаточно надёжно предсказывать затраты на проекты, аналогичные выполненным ранее.
4. Управляемый. Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений, но нет изменений при появлении новых технологий и парадигм.
5. Оптимизированный. Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов.

Развитие

Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки ПО. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration) . На текущий момент последняя версия CMMi — 1.3 (опубликована в ноябре 2010) от 29 сентября 2011 на Wayback Machine .

См. также

• Индивидуальный процесс разработки
• Уровни зрелости управления
• ISO 9000
• ISO/IEC 15504
• ITIL

Ссылки

• от 21 января 2022 на Wayback Machine
• Zádor Dániel Kelemen. (англ.) . SQI Hungarian Software Quality Consulting Institute Ltd. (2007). Архивировано из 21 февраля 2012 года.