(14) Количественное управление процессом (Quantitative Process Management). Цель этой ключевой области состоит в том, чтобы обеспечить возможность управления эффективностью стандартного процесса по реальным и объективно измеряемым данным. Как и любая деятельность в СММ, претворение в жизнь количественного управления процессом является плановой. В таком плане определяются все действия по улучшению процесса, ставятся достижимые цели по его эффективности и устанавливается регулярность измерения и анализа метрик процесса. Суть количественного управления процессом в том, что сначала определяются реальные отклонения текущих значений метрик процесса от целевых значений и выявляются причины, вызвавшие эти отклонения. Далее проводится анализа выявленных причин. На основе результатов анализа вырабатываются требуемые управляющие воздействия для улучшения процесса, и планируется их исполнение.

(15) Управление качеством (Software Quality Management). Целью этой ключевой области является создание возможности управления достижением целевых количественных показателей по качеству как конечного программного продукта, так и всех промежуточных рабочих продуктов разработки. Для обеспечения этого необходимо составление плана управления качеством, согласованного со всеми остальными планами по проекту, и применение той же метрической программы, что и в ключевой области «Количественное управление процессом». Заметим, что если процесс второго уровня зрелости обеспечивает только достижение установленного уровня качества программного продукта, то процесс четвертого уровня дает возможность управлять повышением или понижением достигнутого уровня качества в целях оптимизации баланса «качество-сроки-бюджет».

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

(16) Предотвращение дефектов (Defect Prevention). Цель данной ключевой области – создание условий для результативного выявления и устранения причин возникновения дефектов в прошлом для предотвращения возможности возникновения дефектов того же типа в будущем. Деятельности в этой ключевой области осуществляются также в соответствии с планом, в котором устанавливаются правила проведения анализа дефектов и выявления причин их возникновения. По результатам анализа вырабатывается и планируется к исполнению совокупность мероприятий и действий для исключения причин, вызывающих возникновение дефектов выявленных типов. В результате деятельностей в этой ключевой области должны быть созданы условия, при которых дефекты известных типов не могли бы возникать вообще.

(17) Управление изменениями технологии (Technology Change Management). Цель этой ключевой области заключается в обеспечении установленного порядка в определении эффективности применения передовых технологий и возможности управления внедрением новых. Внедрение новых технологий является плановым мероприятием. План внедрения новых технологий должен быть взаимоувязан со всеми планами, имеющимися в проекте и в организации в целом. Внедрению новых технологий придается особое значение, поскольку добиться лучших результатов невозможно, не используя в процессе разработки новые, более эффективные технологии. При внедрении новых технологий должно отслеживаться соотношение преимуществ от их применения с понесенными затратами на их внедрение. Величина этого соотношения должна играть определяющую роль при принятии решения о внедрении новой технологии, причем оценка этого соотношения сначала осуществляется в одной или нескольких проектных группах. При получении положительных результатов от пилотных внедрений и проведения их анализа, новые технологии внедряются по всему предприятию.

(18) Управление изменениями процесса (Process Change Management). Цель этой последней ключевой области состоит в обеспечении возможности систематического выявления характеристик процесса, требующих улучшения, и автоматизированном управлении улучшением этих характеристик. Для управления изменениями процесса также необходимо иметь план, который должен быть согласован с планами по предотвращению дефектов, внедрению новых технологий, планом разработки программного продукта и другими планами. Все деятельности в этой ключевой области осуществляются в соответствии с порядком, описанным в книге процесса.

15. Характеристика уровней зрелости в модели cmm

Чем выше уровень зрелости данной организации в модели CMM, тем выше вероятность успешного завершения программного проекта в срок, с заданным качеством поставляемого продукта и рамках установленного бюджета. Соответственно, тем выше производительность труда разработчиков и качество поставляемого продукта, и ниже себестоимость разработки и риск неуспеха по причинам, в той или иной мере зависящим от разработчика. Эта сравнительная характеристика уровней зрелости представлена на Рис. 22. В столбце «Структура процесса» схематично представлена структура процесса каждого уровня, а в столбце «Вероятность успеха» дан качественный график распределения вероятности успешного завершения проекта в зависимости от времени, причем вертикальная пунктирная линия означает планируемый срок завершения проекта.

2. Уровни зрелости и области процесса

Ключевые области процесса модели CMM превратились в области процесса модели CMMI; и их число увеличилось с 18 до 22, при этом некоторые области исчезли или слились с другими, добавились новые и названия многих областей изменились, более точно отражая существо деятельностей в данной области:

CAR – Causal Analysis and Resolution – анализ и разрешение причин

CM – Configuration Management – управление конфигурацией

DAR – Decision Analysis and Resolution – анализ и принятие решений

IPM – Integrated Project Management – интегрированное управление проектом

MA – Measurement and Analysis – измерение и анализ

OPD – Organizational Process Definition – определение процесса организации

OPF – Organizational Process Focus – нацеленность процесса организации

OPM – Organizational Process Management – управление процессом организации

OPP – Organizational Process Performance – исполнение процесса организации

OT – Organizational Training – обучение в организации (повышение квалификации)

PI – Product Integration – интеграция продукта

PMC – Project Monitoring and Control – наблюдение за процессом и контроль над ним

PP – Project Planning – планирование проекта

PPQA – Process and Product Quality Assurance – обеспечение качества в процессе и продукте

QPM – Quantitative Project Management – количественное управление проектом

RD – Requirements Development – разработка требований

REQM – Requirements Management – управление требованиями

RSKM – Risk Management – управление рисками

SAM – Supplier Agreement Management – управление договорами с поставщиками

TS – Technical Solution – техническое решение

VAL – Validation – валидация (проверка применимости)

VER – Verification – верификация (проверка корректности реализации)

Рис. 25. Мета-модель целей и практик в модели CMMI

В модели CMMI изменилась структура (Рис. 25), по сравнению с моделью CMM. Теперь ее компонентами теперь являются области процесса (PA – Process Areas), три общие цели (GG – Generic Goals), одни и те же для всех областей процесса, и от 1 до 3 специфических целей (SG – Specific Goals), формулируемых отдельно для каждой из них. Для достижения общих целей предлагается использовать 16 общих практик (GP – Generic Practices), а для достижения специфических целей процесса – от 4 до 14 специфических практик (SP – Specific Practices), характерных для каждой отдельной процессной области. Общее число целей (специальных целей областей процесса) – 49, а общее число деятельностей (специальных практик) – 162. Для каждой из 22 процессных областей в модели определены еще и компоненты «для сведения», которыми являются:

заявление о назначении (Purpose Statement) – описывает назначение данной процессной области;

вводные замечания (Introductory Notes) – описывают главные концепции и обосновывают необходимость данной процессной области;

смежные процессные области (Related Process Areas) – перечисление процессных областей, логически связанных с данной; и

примеры рабочих продуктов (Example Work Products) – взятые из опыта примеры продуктов, создаваемых в конкретных специфических практиках для данной области.

Перечень уровней – тот же, что и в модели CMM.

Уровень 1 (начальный – initial) сохранил свое прежнее название и остался тем же. Процесс разработки на этом уровне непредсказуем, плохо контролируем, является реактивным по своей природе.

Уровень 2 (управляемый – managed) сменил прежнее название «повторяемый» на «управляемый». Процесс уже характеризует проекты, часто является реактивным. Он сохранил все 6 ключевых областей того же 2-го уровня модели CMM под теми же или близкими названиями, превратив их в области процесса и добавив только одну новую область.

Рис. 22. Характеристика уровней зрелости в модели CMM

На первом (начальном) уровне явного и внятного процесса разработки просто нет, но это не значит, что в процессе первого уровня нельзя сделать хороший проект. Такие проекты были и некоторые из них получили хорошие результаты. Но их беда в том, что они непредсказуемы. До момента, пока проект не закончился, неизвестно, закончится ли он вообще или нет, а когда закончится, только тогда можно будет узнать результат. Поэтому в столбце «Структура процесса» представлено отсутствие явной структуры, а кривая распределения вероятности успеха говорит о том, что огромная часть проектов заканчивается с большим превышением срока или не заканчивается вообще.

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

Если на втором уровне фазы процесса замкнуты, то на третьем (определенном) уже и они имеют некоторую структуру и управление ими более сложное; оно включает в себя дополнительные элементы, адресующиеся к структурным элементам фаз. Благодаря этому обстоятельству проекты на третьем уровне, как правило, всегда заканчиваются, хотя большинство все же по разным причинам в срок не успевают. Качественное отличие в распределении вероятности успеха на третьем уровне от предыдущего уровня в том, что пик распределения очень близок к планируемому сроку, и практически нет незаконченных проектов.

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

На пятом (оптимизирующем) уровне пик распределения вероятности очень тонкий, т.е. пятый уровень идеален по части точности планирования. В процесс разработки встроена такая малоизученная вещь, как постоянное самосовершенствование процесса, что схематично представлено в столбце «Структура процесса».

Суммируя все предыдущее, можно сказать, что на первом уровне результат не предсказуем. Разные находки и удачные решения для реализации сделаны только для данного случая – ad hoc. Нет массовости и повторяемости в производстве продукта, нет продуманности: как правило, реализуется первое решение, какое приходит в голову разработчикам. Оно может оказаться удачным для данного случая, но совершенно не годящимся для общего случая. На втором уровне результат предсказуем и имеет место управление процессом. На третьем уровне технология разработки программного продукта и управление существуют, определены и согласованно объединены. На четвертом уровне процесс и продукты, создаваемые в этом процессе, постоянно контролируются измерениями и управляются через эти измерения. Именно поэтому четвертый уровень называется управляемым измерениями, результаты которых регулярно анализируются, по ним предпринимаются определенные управляющие воздействия на сам процесс разработки. Наконец, на пятом уровне имеет место постоянное встроенное и автоматизированное совершенствование процесса разработки.

16. Интегрированная модель зрелости способностей cmmi

    1. История возникновения

По прошествии почти 20 лет после появления и широкого распространения модели CMM накопился новый опыт и открылись новые возможности для дальнейшего совершенствования процесса промышленной разработки программных продуктов. Был создан ряд специализированных моделей CMM для конкретных областей применения. Международные организации разработали стандарты качества (ISO 9000) и стандарты осуществления процессной деятельности (ISO/IEC 15504 – SPICE). Картина разных подходов к созданию программного продукта стала чрезвычайно пестрой и запутанной как для исполнителей, так и для заказчиков (Рис. 23).

В разработке новой модели зрелости участвовали свыше 100 человек, представлявших промышленность, университеты, государственные структуры США и некоммерческие объединения профессионалов, в том числе: U.S. Army, Navy, Air Force, Federal Aviation Administration, National Security Agency, Software Engineering Institute, ADP, AT&T Labs, BAE, Boeing, Computer Sciences Corporation, EER Systems, Ericsson Canada, Ernst and Young, General Dynamics, Harris Corporation, Honeywell, KPMG, Lockheed Martin, Motorola, Northrop Grumman, Pacific Bell, Q-Labs, Raytheon, Reuters, Rockwell Collins, SAIC, Software Productivity Consortium, Sverdrup Corporation, Thomson CSF, TRW. Усилиями этой группы в марте 2002 г. Институт технологии программирования при университете Карнеги-Меллон опубликовал свой технический отчет №11 «Интегрированная модель зрелости способностей CMMI, версия 1.1». Эта модель охватывает 4 инженерные области: разработку систем (System Engineering – SE), технологию программирования (Software Engineering – SW), интегрированную разработку продукта и процесса (Integrated Product and Process Development – IPPD) и работу с поставщиками (Supplier Sourcing – SS).

Рис. 23. Спутанный клубок разных моделей зрелости

Главной причиной, вызвавшей появление этой модели, стала необходимость систематического достижения лучшего, чем CMM, баланса между процессом, технологиями и инженерным составом при разработке программных продуктов высокого качества. В качестве основного предположения было взято известное утверждение Хэмфри (Watts S. Humphrey), что качество программной системы напрямую зависит от качества процесса, в котором она создается: “The quality of the system is governed by the quality of the process used to develop it” [4].

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

Модель CMMI разрабатывалась постепенно и вобрала в себя опыт как SEI, так и двух других заметных линий стандартизации: Международного совета по системному проектированию INCOSE и Союза электронной промышленности EIA (Рис. 24).

Рис. 24. История создания модели CMMI

Дальнейшее изложение относится к версии 1.3 модели CMMI для разработки, опубликованной в ноябре 2010 г. Описание модели в виде технического отчета CMU/SEI-2010-TR-033 содержит 468 страниц текста.