Концептуальная модель CMMI
После выхода в свет СММ и широкого признания, которое она получила в профессиональной среде, работы SEI в этом направлении были продолжены.
Первая Концептуальная модель (Framework), названная CMMI (от CMM Integration), или полностью, Capability Maturity Model Integration (CMMI) (CMU-SEI, 2002), была опубликована в 2002 г. Разрабатывал ее все тот же Институт программной инженерии (SEI) Университета Карнеги-Меллон, а заказчиком опять выступило Министерство обороны CША. К работе привлекались государственные и частные предприятия и организации, ученые и специалисты из университетов и промышленных корпораций.
Удачная попытка SEI по созданию модели зрелости организаций - разработчиков ПО породила волну подражаний применительно к другим проектным организациям (подчеркнем, что проектный характер деятельности - одна из концептуальных основ СММ). Возникли модели-аналоги СММ, и появилось желание регламентировать процесс создания аналогов и обобщить подход СММ, избавившись от специфики разработки ПО. В результате была разработана Концептуальная модель CMMI - СMM Integration.
Цель работы состояла в том, чтобы, проанализировав и обобщив опыт разработки СММ-подобных моделей для разных видов деятельности, создать интегрированную методику оценки развитости и совершенствования процессов организации. Я называю СММ-модели для организаций, занимающихся иной, чем разработка ПО, деятельностью, СММ-подобными, поскольку, строго говоря, само понятие СММ относится только к разработке ПО. По утверждению авторов концептуальной модели CMMI, внедрение в многопрофильной организации разнообразных СММ-подобных моделей, разработанных для разных производственных процессов, оказалось чересчур затратным и сложным делом, главным образом из-за необходимости как-то интегрировать модели для разных процессов. Выходом должна была стать разработка интегрированного подхода к совершенствованию процессов организации, объединяющего три распространенные методики: Capability Maturity Model for Software (SW-CMM) v2.0 draft C, стандарт Electronic Industries Alliance Interim Standard (EIA/IS) 731 и Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98. Все эти методики базируются на СММ, но ориентированы на разные сферы применения: разработку ПО, системную инженерию, интегрированную разработку продуктов.
В основе CMMI лежит несколько основополагающих принципов.
- Концептуальная модель CMMI предназначена для создания на ее основе СММI-модели организации. Соответственно, концептуальная модель CMMI структурирована так, чтобы процесс "выкраивания" нужных процессов для CMMI-модели был простым и прозрачным.
- Явно различаются два разных подхода к оценке и усовершенствованию процессов; соответственно, различаются и варианты CMMI-моделей. Эти варианты называются CMMI с непрерывным1англ. continuous представлением и CMMI со ступенчатым2англ. staged представлением.
- Концептуальная модель CMMI принципиально открыта для включения в нее новых функциональных областей или дисциплин дополнительно к четырем имеющимся (программная инженерия, системная инженерия, интегрированная разработка продуктов и процессов, управление сорсингом и поставками).
Итак, все начинается с определения того, какие процессы войдут в будущую CMMI-модель и что за модель это будет (с непрерывным или ступенчатым представлением).
Структура CMMI-модели
Формальная иерархия процессов в концептуальной модели CMMI такова. На верхнем уровне находятся четыре процессные категории: Управление процессами3англ. Process Management , Управление проектами4англ. Project Management , Разработка5англ. Engineering , Сопровождение6англ. Support . Каждая категория включает несколько процессных областей. Соответствие категорий и областей приведено в таблице 9.1.
Концептуальная модель CMMI дает несколько тривиальных рекомендаций по выбору совокупности процессных областей для включения их в CMMI-модель, но оставляет окончательное решение за организацией. На самом деле, чтобы принять такое решение, нужно достаточно глубоко проанализировать все процессные области и их взаимосвязи.
Процессная область - сложный объект, связанный с другими компонентами CMMI-модели так, как это показано на рис. 9.1.
Из рис. 9.1 видно, что с каждой из процессных областей связываются цели, которые в CMMI называются специфическими8англ. specific . Цели процессной области достигаются путем выполнения входящих в нее специфических практик. Практики, работающие на достижение одной и той же цели процессной области (их может быть несколько), могут находиться на разных уровнях развитости, соотнесенных с процессной областью.
Общие9англ. generic цели связываются с процессной областью косвенно через уровни развитости, для которых они определены. Общие цели достигаются путем выполнения общих практик.
Все это очень напоминает SPICE. Процессные области CMMI соответствуют процессам SPICE, их цели - целям процессов SPICE, специфические и общие практики - основным и общим практикам SPICE. Это неудивительно, поскольку стандарт ISO/IEC 15504 упомянут как один из источников при разработке CMMI. Новацией является появление процессной области "Управление процессами" (Process Management), но это скорее еще одни шаг в направлении, намеченном SPICE.
Как и в СММ и в SPICE, индивидуальные процессы отсутствуют; они "рассыпаны" на практики, которые, выполняясь в совокупности, достигают связанных с процессной областью целей.
Структурно CMMI-модель организована похоже на модель SPICE. Объект верхнего уровня в CMMI-модели - процессная область. Специфические практики - "кирпичики", из которых составляются специфические для данной процессной области процессы. Вообще говоря, у разных процессных областей специфические практики разные. В идеале для достижения специфической цели (целей) процессной области необходимо, чтобы все специфические практики существовали, были устойчивыми, стабильными, эффективными, и это будет означать, что в данной процессной области организация достигла совершенства. В реальности, однако, дело может обстоять иначе: часть практик может отсутствовать совсем, часть - возникать и исчезать, часть - работать неэффективно и т. д. Для того чтобы как-то структурировать возможные ситуации, вводятся уровни развитости и связываются они с процессными областями через практики. Легче всего понять это на примере.
На рис. 9.2 схематически изображен фрагмент CMMI-модели, описывающий процессную область "Сфокусированность на процессах". Два прямоугольника, названные SG1 и SG2, изображают две специфические цели этой процессной области: "Определить возможности для улучшения процессов" и "Спланировать и выполнить работы по совершенствованию процессов". В зависимости от того, на каком уровне развитости находится процессная область, на достижение этих целей будут работать разные специфические практики.
"Лесенка" уровней на рисунке изображена в виде горизонтальных линий с номерами. На уровне 1 присутствует семь специфических практик: три работающих на цель "Определить возможности…" (SP.1.1-1 - SP.1.3-1), и четыре связанных с целью "Спланировать и выполнить…" (SP.2.1-1 - SP.2.4-1). Вот как выглядят эти практики:
А что будет происходить на уровнях 3-5? Могут ли на этих уровнях с нашими целями быть связаны совершенно другие практики? Да, могут, с тем уточнением, что в CMMI все специфические практики, присутствующие только на уровнях не выше первого (т.н. базовые практики), объединяются в отдельные процессные области (базовые процессные области). Остальные практики (т. н. продвинутые практики) собираются в продвинутые процессные области. Процессная область "Сфокусированность на процессах" - базовая, поэтому на уровнях выше первого специфических практик у нее нет.
Теперь нужно разобраться с общими целями и общими практиками. Опять обратимся к рис. 9.2.
Как видно, на каждом уровне имеется ровно одна общая цель, обозначаемая буквами GG10от англ. Generic Goal и номером уровня, и разное число общих практик, обозначаемых буквами GP11от англ. Generic Practice и двумя числами: номером уровня и номером практики на уровне. Общие цели не зависят от конкретной процессной области; достижение их означает улучшение управляемости и повышение эффективности процессов, входящих в процессную область (строго говоря, процессов, построенных из специфических практик, входящих в процессную область). Выглядят они следующим образом:
GG1. | Процесс поддерживает и обеспечивает достижение специфических целей процессной области, преобразуя известные входные данные12в оригинале identifiable input work products в известные результаты. |
GG2. | Процесс институализирован как управляемый. |
GG3. | Процесс институализирован как определенный. |
GG4. | Процесс институализирован как количественно управляемый. |
GG5. | Процесс институализирован как оптимизируемый. |
Естественно, не зависят от процессной области и общие практики, выражающие способ достижения общей цели. По существу набор общих практик "расшифровывает" смысл общей цели. Вот эти общие практики:
Разделение в CMMI-модели общих и специфических целей и практик обеспечивает как бы еще одно измерение при анализе процессов и означает, что понятие уровня развитости не связано с процессными областями, а характеризует способности организации (конечно, в разных областях эти способности могут быть и разными). Таким образом, задача разработки новой CMMI-модели упрощается - достаточно только выбрать процессные области, а полные описания уровней развитости получатся автоматически.
Наполнение, т. е. точное описание специфических и общих целей и практик составляет основное содержание концептуальной модели CMMI. Для этого в модель вводятся субпрактики, описания типовых результатов, а также неформальные описания взаимосвязей практик разных процессных областей.
При построении конкретной CMMI-модели с помощью концептуальной модели необходимо придерживаться определенных ограничений. При несоблюдении этих ограничений полученную модель нельзя считать корректно выведенной из концептуальной модели. Эти ограничения достаточно просты:
- нужно выбрать представление для CMMI-модели (непрерывное или ступенчатое);
- общие и специфические цели, в том виде, как они представлены в концептуальной модели, должны быть включены в CMMI-модель. При этом принципиально важны только названия целей, конкретное содержание может быть сужено или расширено;
- общие и специфические практики из концептуальной модели, или разумные варианты их должны присутствовать в модели; конкретное содержание практик может отличаться от того, что приведено в концептуальной модели;
- субпрактики, типовые результаты, всевозможные комментарии и дополнительные сведения могут отличаться от приведенных в концептуальной модели.
Стоит пояснить только первое ограничение. Непрерывным называется такое представление CMMI-модели, где уровни развитости связываются с процессными областями, т. е. фактически с процессами. Ступенчатое представление соотносит уровни (там они называются уровнями зрелости) с организацией в целом. До сих пор рассматривались только CMMI-модели с непрерывным представлением.
Разница между моделями - в их назначении. Модель с непрерывным представлением предназначена для выявления и анализа порядка выполнения действий по совершенствованию процессных областей (и в конечном итоге организации в целом). Она используется для внутренних целей организации и включает профили развитости процессов.
Модель со ступенчатым представлением подсказывает пути совершенствования управленческих практик в организации и предназначена в основном для сравнения с другими организациями, а также для перехода от SW-CMM к CMMI. Фактически это модель зрелости организации, аналогичная той, что была предложена в CMM. Здесь показано, как построить ее по модели с непрерывным представлением.
Еще одно важное замечание в связи с CMMI касается стандартного производственного процесса организации (СППО), с которым мы встретились в CMM. В CMMI вместо такого процесса введено множество стандартных процессов организации. Смысл его такой же, как и СППО в CMM, но теперь в число стандартных входят не только производственные, но и другие процессы: "множество стандартных процессов организации содержит определения процессов, управляющих всеми активностями организации".
Использование CMMI для оценки развитости процессов. Эволюция CMMI
В отличие от группы SPICE, авторы CMMI не стали включать в Концептуальную модель разделов, регламентирующих оценку (здесь используется термин appraisal) и улучшение процессов. Методология оценки - отдельный продукт SEI, который называется SCAMPI13англ. Standard CMMI Appraisal Method for Process Improvement . В отличие от CMMI, доступной свободно на сайте SEI (http://www.sei.cmu.edu), SCAMPI распространяется только как методический материал, доступный после прохождения обучения и сертификации в SEI.
Концептуальная модель CMMI постоянно развивается и, как утверждают некоторые авторы, в отличие от стандарта ISO/IEC 15504 пользуется все большей популярностью. С помощью Концептуальной модели версии 1.2 в 2006 г. была создана CMMI-модель для процессов разработки (CMU-SEI, 2006), затем появились CMMI-модель для процессов приобретения (CMU-SEI, 2007) и CMMI-модель для услуг (CMU-SEI, 2009). Все эти модели имеют в своей основе общую часть, так называемую CMMI Model Foundation (CMF), содержащую описание базовых 16 процессных областей. Новые модели включают дополнительные специфические процессные области (так, например, CMMI для услуг содержит 24 процессные области), а вся их совокупность называется теперь CMMI v.1.2 Product Suite.
Краткие итоги
В лекции рассмотрена концептуальная модель CMMI, частично объединившая в себе идеи и подходы CMM и SPICE. Изучены сходства и различия указанных моделей и методик. Констатируется, что, в отличие от SPICE, CMMI продолжает активно развиваться вширь, включая все новые процессы и претендуя тем самым на роль универсальной модели оценки развитости процессов.
Вопросы
- В чем состояла цель разработки CMMI?
- Какие процессные категории содержит процессная модель CMMI?
- В чем отличия процессной модели CMMI от процессных моделей CMM и SPICE?
- Что такое процессные области? Какова роль процессных областей в модели CMMI?
- Что такое специфические и общие цели? С чем они связываются?
- Что такое специфические и общие практики?
- Чем CMMI-модель со ступенчатым представлением отличается от модели с непрерывным представлением?
- Какова структура CMMI Product Suite?