Комплексная модель зрелости CMMI® (Capabi­lity Maturity Model Integration) – это широко известный подход к совершенствованию технологических процессов разработки и сопровождения программных продуктов и систем, разработанный в SEI [1]. Специализированная модель CMMI-DEV (CMMI® for Development) используется как руководство по улучшению качества процессов организаций-разработчиков ПО и рекомендуется в том числе для самооценки организации. Актуальной версией CMMI-DEV является версия 1.3, появившаяся в ноябре 2010 года [2]. Несмотря на то, что новые версии руководства не выходили почти шесть лет, интерес к нему со стороны разработчиков ПО и руководителей предприятий не уменьшается. Продолжает продвигать эту модель и компания «Kondakov Consulting» (http://consulting.konda kov.ru) – первая в России организация, сертифицированная для проведения оценивания организаций согласно модели CMMI®.

Фундаментальным структурным элементом CMMI® является процессная область. Под нею понимается группа взаимосвязанных практик, совместное выполнение которых позволяет организации достичь набора целей, признанных важными для улучшений в этой области. Под процессами в модели CMMI® понимаются работы, которые рассматриваются как выполнение практик, при этом под практикой понимается некоторая деятель-ность, способствующая достижению связанной с ней цели. Цели разделяются на общие (generic goal – GG) и специфические (specific goal – SG). Соответственно практики, связанные с общей целью, также называются общими (generic practice – GP), а практики, связанные со специфической целью, – специфическими (specific practice – SP). GG относятся ко всем процессным областям, а SG всегда сформулированы для конкретной процессной области. Для каждой специфической практики в модели определяются типичные рабочие продукты, представляющие собой образцы результатов ее выполнения. В CMMI-DEV определены 22 процессные области [2].

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

Требования к проведению оценивания в рамках модели CMMI® сформулированы в документе ARC (Appraisal Requirements for CMMI®) [3]. Согласно ему, любой метод оценки качества процесса основывается на анализе проверенных экспертами свидетельств о реализации связанных с процессной областью общих и специфических практик – так называемых объективных свидетельств.

Авторы данной статьи считают весьма полезным внедрение модели CMMI® или используемых в ней методик для оценки и самооценки зрелости процессов в отечественных компаниях, занимающихся разработкой ПО (как частной, так и государственной форм собственности). Однако следует отметить, что, поскольку ARC не содержит описания конкретных способов оценивания объективных свидетельств и качества реализации практик, практическое применение данной методологии упирается в неопределенность того, какие методы и алгоритмы следует применять для получения оценок. В статье [4] модель CMMI® была рассмотрена более детально, в ней также рассматривалась возможность использования методов нечеткой логики для вывода уровней выполнения практик на основе анализа имеющихся объективных свидетельств.

В данной статье рассматривается методика оценки уровня выполнения практик, основанная на байесовском подходе. Формула Байеса [5] используется для получения вероятностных оценок истинности гипотез о том, что степень выполнения практик соответствует каждому из уровней, определенных в CMMI®. Предлагаемая методика базируется на подходе к оцениванию качества управленческих решений в железнодорожной отрасли, предложенном в [6] и [7]. В частности, в [7] одним из авторов данной статьи был предложен простой способ определения условных вероятностей, используемых в формуле Байеса, как частот попадания экспертных отметок по интегрированной группе показателей качества в пересекающиеся интервалы 10-балльной метрической шкалы, соответствующие уровням ранжирования качества решения.

Применение формулы Байеса упрощает задачу оценивания по сравнению с методами нечеткой логики: уменьшается доля самовольности ЛПР, неизбежной при определении таких параметров нечеткого логического вывода, как виды и формы функций принадлежности, способ реализации нечетких логических операций и т.д. [8]. Подобное упрощение целесообразно, так как высокая точность при оценивании выполнения практик в любом случае невозможна да и не требуется в силу неточности исходных данных и экспертного способа получения оценок. Здесь уместно вспомнить мнение выдающегося математика, академика АН СССР Н.Н. Моисеева, который в контексте обсуждения экспертиз и неформальных процедур в [9] утверждал, что иногда для нужд практики достаточно использовать весьма грубые оценки. Кроме того, байесовский подход позволяет сгладить разногласия, неизбежно возникающие между экспертами (даже при условии наличия у каждого из них достаточного уровня профессиональной компетентности, исключающего сильные разногласия в оценивании), и освободить лицо, принимающее решение, от необходимости рассчитывать согласованность оценок группы экспертов [10]. Дополнительным доводом в пользу применения байесовского подхода в новом контексте является то, что он давно и успешно используется при принятии решений в условиях неопределенности: при решении задач организационного управления, в том числе задач управления рисками [11–13], при оценивании качества продукции на основании случайного выборочного контроля.

Байесовское оценивание уровней выполнения практик процессной области

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

Обозначим через Hi гипотезу (hypothesis) вида «Выбранная практика достигает уровня реализации i», где  – порядковый номер уровня из таблицы 1. Далее предположим, что в распоряжении лица, принимающего решение, имеется n объективных свидетельств (evidence) за или против каждой из гипотез Hi. В качестве свидетельств могут использоваться документы, представляющие результат реализации практики либо являющиеся следствием ее выполнения, а также устные или письменные заявления, подтверждающие осуществление (или невыполнение) практики, предоставляемые ее исполнителями. Факт наличия каждого из свидетельств обозначим через ej. Отметим, что в отличие от гипотез свидетельства ej никак не упорядочены по качеству (значимости) и пронумерованы в произвольном порядке.

1.    Перед началом оценивания лицо, принимающее решение, формирует априорное распределение вероятностей P(Hi) на множестве гипотез. Каждая вероятность P(Hi) рассматривается как степень уверенности этого лица в справедливости i-й гипотезы об уровне выполнения практики до начала оценивания, то есть до получения каких-либо свидетельств за или против гипотезы. Так как априорная информация об уровне выполнения практики может быть полностью неопределенной, вероятности P(Hi) могут иметь значение 1/5, . При наличии достаточного обоснования допускается использование и неравномерного распределения априорных вероятностей на множестве гипотез. Например, крайние гипотезы H1 и H5 представля- ются менее вероятными, чем все остальные, поэтому их априорные вероятности могут иметь более низкие значения. Кроме того, в качестве априорных вероятностей P(Hi) могут использоваться апостериорные байесовские вероятности P(Hi | e1, e2, …, en), полученные на предыдущей итерации оценивания.

2.    Условная вероятность P(ej | Hi) понимается как вероятность истинности свидетельства ej в предположении, что истинна гипотеза Hi, и показывает, насколько данные, полученные из свидетельства, соответствуют i-й гипотезе об уровне выполнения практики. Значение этой условной вероятности получается путем агрегации полученных балльных экспертных оценок имеющегося свидетельства. Назначенные экспертами баллы показывают, насколько, по их мнению, каждая из гипотез подтверждается полученным свидетельством, и отражают степени предпочтения экспертами, производящими оценивание, той или иной гипотезы о достижении определенного уровня реализации рассматриваемой практики.

3.    Условная вероятность P(Hi | e1, e2, …, en) понимается как степень уверенности лица, производящего оценивание, в справедливости i-й гипотезы об уровне выполнения практики после получения всех свидетельств ej, . В соответствии с теоремой Байеса и при условии независимости всех свидетельств она вычисляется как апостериорная байесовская вероятность:

(1)

4.    Полученное по формуле (1) апостериорное распределение вероятностей P(Hi | e1, e2, …, en) на множестве гипотез, , является итоговой оценкой уровня выполнения практики и показывает, насколько правдоподобными по завершении процедуры оценивания стали гипотезы о том, что степень выполнения рассматриваемой практики достигла каждого из уровней.

Рассмотрим простой способ получения и агрегации экспертных оценок для определения условных вероятностей P(ej | Hi) путем обработки объективных свидетельств. В каждом конкретном случае набор объективных свидетельств определяется как целями оцениваемой организации и типом разрабатываемых продуктов, так и принятым в организации способом фиксации требований к разработке.

При необходимости каждое объективное свидетельство может быть оценено в ходе нескольких экспертиз с использованием различных экспертов или экспертных групп. Чем больше используется объективных свидетельств и проводится экспертиз (при условии адекватной профессиональной компетентности проводящих их экспертов), тем точнее будет полученная общая оценка уровня выполнения соответствующих практик. Для фиксации результатов экспертизы объективных свидетельств уместно использовать контрольные списки (check­list), широко применяемые при оценивании качества процессов или продукции [14].

Экспертные оценки соответствия свидетельств ej гипотезам о степени выполнения некоторой практики CMMI P(ej | Hi) формируются по результатам обработки контрольных списков следующим образом.

1.    Результаты k-й экспертизы контрольного списка по свидетельству ej суммируются, а итоговое значение ejk переводится в 10-балльную шкалу для обеспечения однородности экспертных оценок.

2.    Для каждого свидетельства ej подсчитываются относительные частоты попадания всех итоговых значений ejk в частично пересекающиеся интервалы, определенные на 10-балльной шкале и со- ответствующие пяти гипотезам из таблицы 1, например, NY: [0; 1], NI: [1; 2], PI: [2; 6], LI: [5; 9], FI: [9; 10]. Пересечение интервалов введено намеренно с целью моделирования неопределенности, возникающей при экспертном оценивании, в частности, в связи с использованием свидетельств разного уровня значимости (качества). Более того, для различных свидетельств степень пересечения интервалов может варьироваться в зависимости от уровня их значимости.

3.    Полученные относительные частоты и принимаются за оценки условных вероятностей соответствия свидетельств ej гипотезам об уровне выполнения практики P(ej | Hi). Они, разумеется, яв- ляются очень грубым приближением к условным вероятностям, но, как упоминалось выше, в случае оперирования весьма неопределенными исходными данными большая точность и не требуется.

Оценивание практик процессной области «Разработка требований»

Назначение процессной области «Разработка требований» (Requirement Development, RD) – выявление, анализ и фиксация требований заказчика, а также технических требований и ко всему продукту, и к его компонентам. Требования касаются как в целом функциональности, безопасности, надежности, модифицируемости и масштабируемости продукта, его интегрируемости с внешними приложениями, так и конкретных принимаемых архитектурных решений и определяют действия всех участников проекта по его разработке.

В процессной области имеются следующие специфические цели SG и связанные с ними практи- ки SP.

1.    SG1 – Develop Customer Requirements. Сбор и перевод в требования заказчика пожеланий всех заинтересованных лиц, их ожиданий, ограничений и представлений об интерфейсах разрабатываемого продукта.

·     SP 1.1 – Elicit Needs. Выявление пожеланий заинтересованных лиц, их ожиданий, ограничений и представлений об интерфейсах разрабатываемого продукта на всех фазах жизненного цикла.

·     SP 1.2 – Transform Stakeholders Needs into Customer Requirements. Преобразование пожеланий заинтересованных лиц, их ожиданий, ограничений и представлений об интерфейсах разрабатываемого продукта в перечень требований заказчика с приоритетами.

Результатами выполнения практик цели SG1 могут являться

-     перечень требований заказчика с приоритетами;

-     порядок проведения верификации;

-     порядок проведения валидации и т.д.

2.    SG2 – Develop Product Requirements. Разра- ботка технических требований к продукту и его компонентам путем совершенствования и уточнения требований заказчика.

·     SP 2.1 – Establish Product and Product Component Requirements. Установление и сохранение технических требований к продукту и его компонентам на основе требований заказчика.

·     SP 2.2 – Allocate Product Component Requirements. Распределение требований по компонентам продукта.

·     SP 2.3 – Identify Interface Requirements. Выявление интерфейсных требований (то есть требований к способам информационного обмена между программными функциями, объектами и другими элементами).

Результатами выполнения практик цели SG2 могут являться

-     общие требования к продукту;

-     требования к компонентам продукта, в том числе таблицы распределения требований по компонентам;

-     требования к архитектуре, в том числе к связям между компонентами;

-     требования к интерфейсам между элементами компонентов;

-     проектные ограничения, в том числе внешние, и т.д.

3.    SG3 – Analyze and Validate Requirements. Анализ и валидация требований.

·     SP 3.1 – Establish Operational Concepts and Scenarios. Установление общей концепции процесса разработки и набора реализующих ее сценариев.

·     SP 3.2 – Establish of Definition of Required Functionality and Quality Attributes. Определение требуемой функциональности и критериев качества.

·     SP 3.3 – Analyze Requirements. Анализ требований с точки зрения выявления их необходимости и достаточности.

·     SP 3.4 – Analyze Requirements to Achieved Balance. Анализ требований с точки зрения поиска компромисса между пожеланиями заинтересованных лиц и выявленными ограничениями.

·     SP 3.5 – Validate Requirements. Анализ и проверка требований для гарантии того, что разрабатываемый продукт будет функционировать корректно в среде конечного пользователя.

Результатами выполнения практик цели SG3 могут являться

-     общая концепция процесса разработки;

-     концепции процессов разработки компонентов, установки продукта, его сопровождения и поддержки;

-     сценарии, реализующие общую концепцию процесса;

-     требования к функциональности продукта;

-     сформулированные критерии качества и технической эффективности;

-     варианты использования продукта;

-     диаграммы активности для вариантов использования;

-     функциональная архитектура (выявленные методы и их взаимодействие);

-     результаты объектно-ориентированного анализа функциональной архитектуры;

-     отчет о недостатках системы требований и рекомендации по их устранению;

-     оценка рисков, связанных с требованиями;

-     новые дополнительные требования и ограничения.

Нетрудно заметить, что структура и содержание процессной области RD на практике в достаточной степени отражается в документации, сопровождающей разработку ПО, в том числе и в отечественной практике. В частности, многие позиции от- ражаются в техническом задании на разработку автоматизированной системы (ТЗ АС), соответствующем требованиям ГОСТ 34.602-89.

Таким образом, экспертная оценка наполнения соответствующих пунктов ТЗ АС может служить объективным свидетельством выполнения специфической практики SP 2.2, например:

·     OE1 – п. 4.1.1.1 «Перечень подсистем, их назначение и основные характеристики, требования к числу уровней иерархии и степени централизации системы»;

·     OE2 – п. 4.1.8 «Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы»;

·     OE3 – п. 4.2.1 «Перечень функций, задач или их комплексов, подлежащих автоматизации, для каждой подсистемы».

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

Пример байесовского оценивания практики SP 2.2 процессной области RD

Для вычисления байесовской оценки степени выполнения практики SP 2.2 используем объективные свидетельства OE1–OE4, предложенные выше. Рассмотрим процесс формирования оценки уровня выполнения практики. Сначала проводятся экспертизы объективных свидетельств по контрольным спискам, составленным в соответствии с целями предприятия и типом разрабатываемого продукта. Например, контрольный список для оценки раз- дела ТЗ «Перечень функций, задач или их комплексов, подлежащих автоматизации, для каждой подсистемы» (как свидетельства ОЕ3) может соответствовать приведенному в таблице 2.

Таблица 2

Пример контрольного списка для оценивания свидетельства ОЕ3

Table 2

A check list example to estimate ОЕ3 evidence

Вопрос	Шкала оценивания
1. Имеется ли в ТЗ соответствующий раздел?	0 –      не имеется 1 –      имеется
2.m Указан ли перечень функций для m-й подсистемы?	0 –      перечень отсутствует 1 –      перечень имеется
3.m Описаны ли для m-й подсистемы автоматизируемые ею процессы?	0 –      не описаны 1 –      описаны
4.m Хорошо ли отделены функции m-й подсистемы друг от друга?	0 –      описание не позволяет судить об этом 1 –      описание свидетельствует о наличии большого количества пересечений функциональности 2 –      пересечения есть, но незначительные 3 –      функции хорошо отделены друг от друга
5.m Полностью ли реализуют автоматизируемые m-й подсистемой процессы ее функции?	0 –      описание не позволяет судить об этом 1 –      описание свидетельствует о значительной неполноте функциональности 2 –      полнота реализации автоматизируемых процессов достаточно высока 3 –      функции полностью реализуют автоматизируемые подсистемой процессы
6. Не дублируют ли функции разных подсистем друг друга?	0 –      описание не позволяет судить об этом 1 –      есть большое количество пересечений функциональности разных подсистем 2 –      примерно половина подсистем имеет пересекающуюся функциональность 3 –      пересечений функциональности мало 4 –      функции разных подсистем не дублируют друг друга
…	…

В предлагаемом варианте контрольного списка вопросы 2–5 повторяются блоками по N вопросов, где N – число подсистем, составляющих разрабатываемую АС:

Обработка результатов экспертиз (то есть за- полненных контрольных списков) производится в соответствии с алгоритмом вычисления частотных оценок условных вероятностей P(ej | Hi), рассмотренным выше. Приведем пример расчета условных вероятностей P(ej | Hi) и итоговых апостериорных байесовских оценок P(Hi | e1, e2, …, en) уровней выполнения специфической практики SP 2.2 с использованием формулы Байеса. В таблице 3 показан пример расчета условных вероятностей P(ej | Hi), , , на основании агрегирования преобразованных в 10-балльную шкалу оценок пяти экспертов, полученных по результатам обработки заполненных ими контрольных списков. Результаты вычисления апостериорных байесовских оценок уровней выполнения практики SP 2.2 приведены в таблице 4.

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

Заключение

В статье предложено применение байесовского подхода к оцениванию уровня выполнения практик, определенных в модели CMMI®. Данный подход предполагает использование формулы Байеса для построения распределения апостериорных вероятностей на множестве гипотез о том, что сте- пень реализации рассматриваемой практики достигла некоторого возможного уровня, исходя из полученных результатов экспертного оценивания имеющихся объективных свидетельств. Подход не накладывает никаких ограничений на количество, качество и конкретный перечень используемых свидетельств, а также на состав оценивающей экспертной группы и применим не только для специфических практик процессных областей, но и для общих практик при условии, что имеются объективные свидетельства, позволяющие произвести экспертное оценивание. Для унификации результатов экспертизы предлагается использование контрольных списков, а для упрощения агрегации полученных оценок и их пересчета в условные вероятности гипотез – перевод всех оценок в единую (например 10-балльную) шкалу.

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

Преимущества предлагаемого байесовского подхода:

-     упрощение процедуры оценивания по сравнению с использованием методов нечеткой логики;

-     вероятностный, более объективный, характер экспертных оценок уровня выполнения практик, а также естественное сглаживание разногласий, возникающих между экспертами;

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

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

Авторы глубоко благодарны крупному специалисту в области проблем управления на железнодорожном транспорте профессору А.Е. Красковскому, поддержавшему идею применения байесовского подхода при оценивании качества управленческих решений, а также выражают искреннюю признательность председателю Совета директоров группы компаний Digital Design А.Р. Фёдорову и бывшему начальнику Департамента информатизации и корпоративных процессов управления ОАО «РЖД» А.В. Илларионову, благодаря которым несколько лет назад открыли для себя модель CMMI®.

Литература

1.     Ахен Д.М., Клауз А., Тернер Р. CMMI®: Комплексный подход к совершенствованию процессов. Практическое введение в модель; [пер. с англ.]. М.: МФК, 2005. 330 с.

2.     CMMI® for Development (CMMI-DEV, V1.3). Improving processes for developing better products and services. CMU/SEI-2010-TR-033. ESC-TR-2010-033. Software Eng. Inst. CMMI Product Team, November 2010.

3.     Appraisal Requirements for CMMI (ARC, V1.2). CMU/SEI-2006-TR-011. ESC-TR-2006-011. Software Eng. Inst. SCAMPI Upgrade Team, August 2006.

4.     Кожомбердиева Г.И., Гарина М.И., Бураков Д.П. Об использовании аппарата теории принятия решений в задачах оценивания согласно модели CMMI® // Программные продукты и системы. 2013. № 4. С. 117–124.

5.     Вентцель Е.С., Овчаров Л.А. Теория вероятностей и ее инженерные приложения. М.: Наука, 1988. 480 с.

6.     Кожомбердиева Г.И., Красковский А.Е.  Байесовский подход к оценке качества управленческих решений // Интеллектуальные системы на транспорте: матер. III Междунар. науч.-практич. конф. «ИнтеллектТранс-2013». СПб: Изд-во ПГУПС, 2013. С. 384–391.

7.     Кожомбердиева Г.И., Красковский А.Е. Способ определения условных вероятностей при байесовском оценивании качества управленческих решений на железнодорожном транспорте // Интеллектуальные системы на транспорте: матер. IV Междунар. науч.-практич. конф. «ИнтеллектТранс-2014». СПб: Изд-во ПГУПС, 2014. С. 412–418.

8.     Леоненков А.В. Нечеткое моделирование в среде MATLAB и fuzzyTECH. СПб: БХВ-Петербург, 2005. 736 с.

9.     Моисеев Н.Н. Математические задачи системного анализа: учеб. пособие. М.: ЛИБРОКОМ, 2012. 488 с.

10.  Кендэл М. Ранговые корреляции. Серия: Зарубежные статистические исследования; [пер. с англ.]. М.: Статистика, 1975. 216 с.

11.  Райфа Г. Анализ решений (введение в проблему выбора в условиях неопределенности); [пер. с англ.]. М.: Наука, 1977. 408 с.

12.  Моррис У.Т. Наука об управлении: байесовский подход; [пер. с англ.]. М.: Мир, 1971. 304 с.

13.  Уткин Л. В. Анализ риска и принятие решений при не- полной информации. СПб: Наука, 2007. 404 с.

14.  Scriven M. The logic and methodology of checklists. URL: http://www.wmich.edu/sites/default/files/attachments/u350/2014/logic&methodology_dec07.pdf (дата обращения: 01.07.2016).