ArticlePDF Available

Использование формулы Байеса при оценивании выполнения практик модели CMMI®

Authors:
Программные продукты и системы / Software & Systems 1 (30) 2017
67
УДК 004.413; 519.816; 519.226.3 Дата подачи статьи: 15.07.16
DOI: 10.15827/0236-235X.117.067-074 2017. Т. 30. № 1. С. 67–74
ИСПОЛЬЗОВАНИЕ ФОРМУЛЫ БАЙЕСА
ПРИ ОЦЕНИВАНИИ ВЫПОЛНЕНИЯ ПРАКТИК МОДЕЛИ CMMI®
Г.И. Кожомбердиева, к.т.н., доцент, kgi-liizht@yandex.ru;
Д.П. Бураков, к.т.н., доцент, burakovdmitry8@gmail.com;
М.И. Гарина, к.т.н., доцент, migarina@gmail.com
(Петербургский государственный университет путей сообщения,
Московский просп., 9, г. Санкт-Петербург, 190031, Россия)
Статья посвящена методике экспертного оценивания (на основе объективных свидетельств) степени осуществле-
ния практик, обеспечивающих реализацию целей процессных областей модели CMMI®, разработанной в Институте
программной инженерии Университета Карнеги–Меллона (SEI). Формирование подобных оценок необходимо для по-
лучения вывода об уровне зрелости процессов разработки ПО, достигнутом организацией-разработчиком.
В условиях неопределенности и/или неполноты исходной информации о выполнении практик CMMI® с целью
повышения степени доверия к принимаемым экспертами-оценщиками решениям целесообразно использовать инстру-
ментарий, применяемый для принятия решений в слабо формализованных предметных областях. Ранее в работах ав-
торов рассматривались два подхода к формированию оценок: методы нечеткой логики и методы многокритериальной
классификации.
В настоящей статье предпринимаются попытки сделать процедуру экспертного оценивания еще более простой и
гибкой, расширить возможности ее использования, повысить объективность оценки. Предлагается подход, основан-
ный на использовании известной в теории вероятностей теоремы гипотез (формулы Байеса). При этом степень реали-
зации практики CMMI® оценивается через распределение вероятностей на множестве гипотез о том, что степень реа-
лизации достигла одного из предопределенных уровней. Под байесовской оценкой степени реализации практики по-
нимается апостериорное распределение вероятностей, пересмотренное и уточненное в ходе оценивания.
Значения условных вероятностей, используемых при вычислении байесовской оценки, показывают, насколько ги-
потезы об уровне выполнения практики подтверждаются полученными объективными свидетельствами.
Ключевые слова: CMMI®, процессная область, уровни зрелости, уровни возможностей, оценивание, объективные
свидетельства, теория принятия решений, формула Байеса, байесовский подход, экспертное оценивание.
Комплексная модель зрелости 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]. Согласно
Программные продукты и системы / Software & Systems 1 (30) 2017
68
ему, любой метод оценки качества процесса осно-
вывается на анализе проверенных экспертами сви-
детельств о реализации связанных с процессной
областью общих и специфических практик – так
называемых объективных свидетельств.
Авторы данной статьи считают весьма полез-
ным внедрение модели CMMI® или используемых
в ней методик для оценки и самооценки зрелости
процессов в отечественных компаниях, занимаю-
щихся разработкой ПО (как частной, так и государ-
ственной форм собственности). Однако следует от-
метить, что, поскольку ARC не содержит описания
конкретных способов оценивания объективных
свидетельств и качества реализации практик, прак-
тическое применение данной методологии упира-
ется в неопределенность того, какие методы и ал-
горитмы следует применять для получения оценок.
В статье [4] модель CMMI® была рассмотрена бо-
лее детально, в ней также рассматривалась возмож-
ность использования методов нечеткой логики для
вывода уровней выполнения практик на основе
анализа имеющихся объективных свидетельств.
В данной статье рассматривается методика
оценки уровня выполнения практик, основанная на
байесовском подходе. Формула Байеса [5] исполь-
зуется для получения вероятностных оценок ис-
тинности гипотез о том, что степень выполнения
практик соответствует каждому из уровней, опре-
деленных в CMMI®. Предлагаемая методика бази-
руется на подходе к оцениванию качества управ-
ленческих решений в железнодорожной отрасли,
предложенном в [6] и [7]. В частности, в [7] одним
из авторов данной статьи был предложен простой
способ определения условных вероятностей, ис-
пользуемых в формуле Байеса, как частот попада-
ния экспертных отметок по интегрированной
группе показателей качества в пересекающиеся ин-
тервалы 10-балльной метрической шкалы, соответ-
ствующие уровням ранжирования качества реше-
ния.
Применение формулы Байеса упрощает задачу
оценивания по сравнению с методами нечеткой ло-
гики: уменьшается доля самовольности ЛПР, неиз-
бежной при определении таких параметров нечет-
кого логического вывода, как виды и формы функ-
ций принадлежности, способ реализации нечетких
логических операций и т.д. [8]. Подобное упроще-
ние целесообразно, так как высокая точность при
оценивании выполнения практик в любом случае
невозможна да и не требуется в силу неточности
исходных данных и экспертного способа получе-
ния оценок. Здесь уместно вспомнить мнение вы-
дающегося математика, академика АН СССР
Н.Н. Моисеева, который в контексте обсуждения
экспертиз и неформальных процедур в [9] утвер-
ждал, что иногда для нужд практики достаточно
использовать весьма грубые оценки. Кроме того,
байесовский подход позволяет сгладить разногла-
сия, неизбежно возникающие между экспертами
(даже при условии наличия у каждого из них доста-
точного уровня профессиональной компетентно-
сти, исключающего сильные разногласия в оцени-
вании), и освободить лицо, принимающее решение,
от необходимости рассчитывать согласованность
оценок группы экспертов [10]. Дополнительным
доводом в пользу применения байесовского под-
хода в новом контексте является то, что он давно и
успешно используется при принятии решений в
условиях неопределенности: при решении задач
организационного управления, в том числе задач
управления рисками [11–13], при оценивании каче-
ства продукции на основании случайного выбороч-
ного контроля.
Байесовское оценивание уровней
выполнения практик процессной области
Рассмотрим предлагаемый способ применения
байесовского подхода к оцениванию уровней вы-
полнения практик процессных областей CMMI.
В модели CMMI степень выполнения каждой прак-
тики может достигать одного из пяти уровней, упо-
рядоченных по возрастанию качества реализации.
Возможные уровни выполнения практики пред-
ставлены в таблице 1.
Обозначим через Hi гипотезу (hypothesis) вида
«Выбранная практика достигает уровня реализа-
ции i», где
5,1i
порядковый номер уровня из
таблицы 1. Далее предположим, что в распоряже-
нии лица, принимающего решение, имеется n объ-
ективных свидетельств (evidence) за или против
каждой из гипотез Hi. В качестве свидетельств мо-
гут использоваться документы, представляющие
результат реализации практики либо являющиеся
следствием ее выполнения, а также устные или
письменные заявления, подтверждающие осу-
ществление (или невыполнение) практики, предо-
ставляемые ее исполнителями. Факт наличия каж-
дого из свидетельств обозначим через ej. Отметим,
что в отличие от гипотез свидетельства ej никак не
упорядочены по качеству (значимости) и пронуме-
рованы в произвольном порядке.
1. Перед началом оценивания лицо, принима-
ющее решение, формирует априорное распределе-
ние вероятностей P(Hi) на множестве гипотез. Каж-
дая вероятность P(Hi) рассматривается как степень
уверенности этого лица в справедливости i-й гипо-
тезы об уровне выполнения практики до начала
оценивания, то есть до получения каких-либо сви-
детельств за или против гипотезы. Так как априор-
ная информация об уровне выполнения практики
может быть полностью неопределенной, вероятно-
сти P(Hi) могут иметь значение 1/5,
5,1i
. При
наличии достаточного обоснования допускается
использование и неравномерного распределения
априорных вероятностей на множестве гипотез.
Например, крайние гипотезы H1 и H5 представля-
Программные продукты и системы / Software & Systems 1 (30) 2017
69
ются менее вероятными, чем все остальные, по-
этому их априорные вероятности могут иметь бо-
лее низкие значения. Кроме того, в качестве апри-
орных вероятностей P(Hi) могут использоваться
апостериорные байесовские вероятности P(Hi | e1,
e2, …, en), полученные на предыдущей итерации
оценивания.
2. Условная вероятность P(ej | Hi) понимается
как вероятность истинности свидетельства ej в
предположении, что истинна гипотеза Hi, и показы-
вает, насколько данные, полученные из свидетель-
ства, соответствуют i-й гипотезе об уровне выпол-
нения практики. Значение этой условной вероятно-
сти получается путем агрегации полученных
балльных экспертных оценок имеющегося свиде-
тельства. Назначенные экспертами баллы показы-
вают, насколько, по их мнению, каждая из гипотез
подтверждается полученным свидетельством, и от-
ражают степени предпочтения экспертами, произ-
водящими оценивание, той или иной гипотезы о
достижении определенного уровня реализации рас-
сматриваемой практики.
3. Условная вероятность P(Hi | e1, e2, …, en) по-
нимается как степень уверенности лица, произво-
дящего оценивание, в справедливости i-й гипотезы
об уровне выполнения практики после получения
всех свидетельств ej,
nj ,1
. В соответствии с тео-
ремой Байеса и при условии независимости всех
свидетельств она вычисляется как апостериорная
байесовская вероятность:
1
12
5
12
1
( , , )
( ) ( ) ( ) ( ) .
( ) ( ) ( ) ( )
in
i i i n i
j j j n j
j
P H e e
P H P e H P e H P e H
P H P e H P e H P e H
 
 
(1)
4. Полученное по формуле (1) апостериорное
распределение вероятностей P(Hi | e1, e2, …, en) на
множестве гипотез,
5,1i
, является итоговой
оценкой уровня выполнения практики и показы-
вает, насколько правдоподобными по завершении
процедуры оценивания стали гипотезы о том, что
степень выполнения рассматриваемой практики
достигла каждого из уровней.
Рассмотрим простой способ получения и агре-
гации экспертных оценок для определения услов-
ных вероятностей P(ej | Hi) путем обработки объек-
тивных свидетельств. В каждом конкретном случае
набор объективных свидетельств определяется как
целями оцениваемой организации и типом разраба-
тываемых продуктов, так и принятым в организа-
ции способом фиксации требований к разработке.
При необходимости каждое объективное свиде-
тельство может быть оценено в ходе нескольких
экспертиз с использованием различных экспертов
или экспертных групп. Чем больше используется
объективных свидетельств и проводится экспертиз
(при условии адекватной профессиональной ком-
петентности проводящих их экспертов), тем точнее
будет полученная общая оценка уровня выполне-
ния соответствующих практик. Для фиксации ре-
зультатов экспертизы объективных свидетельств
уместно использовать контрольные списки (check-
list), широко применяемые при оценивании каче-
ства процессов или продукции [14].
Экспертные оценки соответствия свидетельств
ej гипотезам о степени выполнения некоторой
практики CMMI P(ej | Hi) формируются по резуль-
татам обработки контрольных списков следующим
образом.
1. Результаты k экспертизы контрольного
списка по свидетельству ej суммируются, а итого-
вое значение ejk переводится в 10-балльную шкалу
для обеспечения однородности экспертных оценок.
2. Для каждого свидетельства ej подсчитыва-
ются относительные частоты попадания всех ито-
говых значений ejk в частично пересекающиеся ин-
тервалы, определенные на 10-балльной шкале и со-
Таблица 1
Уровни выполнения практики CMMI Table 1
CMMI practice implementation levels
Описание
1
Практика отсутствует.
Отсутствуют свидетельства, позволяющие признать практику реализованной
2
Практика не реализована.
Предоставленные свидетельства не позволяют заключить, что практика
осуществлена, отмечены явные недостатки
3
Практика частично реализована.
Предоставленные свидетельства противоречивы: некоторые данные указывают
на выполнение практики, некоторые – на невыполнение. Отмечены недостатки
4
Практика в основном реализована.
Имеется достаточно убедительных объективных свидетельств, отмечены отдель-
ные недостатки
5
Практика полностью реализована.
Имеется достаточно убедительных объективных свидетельств, отсутствуют
недостатки
Программные продукты и системы / Software & Systems 1 (30) 2017
70
ответствующие пяти гипотезам из таблицы 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 Com-
ponent Requirements. Установление и сохранение
технических требований к продукту и его компо-
нентам на основе требований заказчика.
SP 2.2 Allocate Product Component Require-
ments. Распределение требований по компонентам
продукта.
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
могут являться
общая концепция процесса разработки;
концепции процессов разработки компонен-
тов, установки продукта, его сопровождения и под-
держки;
сценарии, реализующие общую концепцию
процесса;
требования к функциональности продукта;
сформулированные критерии качества и
технической эффективности;
Программные продукты и системы / Software & Systems 1 (30) 2017
71
варианты использования продукта;
диаграммы активности для вариантов ис-
пользования;
функциональная архитектура (выявленные
методы и их взаимодействие);
результаты объектно-ориентированного
анализа функциональной архитектуры;
отчет о недостатках системы требований и
рекомендации по их устранению;
оценка рисков, связанных с требованиями;
новые дополнительные требования и огра-
ничения.
Нетрудно заметить, что структура и содержание
процессной области 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 используем объектив-
ные свидетельства OE1OE4, предложенные выше.
Рассмотрим процесс формирования оценки уровня
выполнения практики. Сначала проводятся экспер-
тизы объективных свидетельств по контрольным
спискам, составленным в соответствии с целями
предприятия и типом разрабатываемого продукта.
Например, контрольный список для оценки раз-
дела ТЗ «Перечень функций, задач или их комплек-
сов, подлежащих автоматизации, для каждой под-
системы» (как свидетельства ОЕ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 число подсистем, составляющих разрабаты-
ваемую АС:
1, .mN
Обработка результатов экспертиз (то есть за-
полненных контрольных списков) производится в
Программные продукты и системы / Software & Systems 1 (30) 2017
72
соответствии с алгоритмом вычисления частотных
оценок условных вероятностей P(ej | Hi), рассмот-
ренным выше. Приведем пример расчета условных
вероятностей P(ej | Hi) и итоговых апостериорных
байесовских оценок P(Hi | e1, e2, …, en) уровней вы-
полнения специфической практики SP 2.2 с ис-
пользованием формулы Байеса. В таблице 3 пока-
зан пример расчета условных вероятностей
P(ej | Hi),
5,1i
,
4,1j
, на основании агрегирова-
ния преобразованных в 10-балльную шкалу оценок
пяти экспертов, полученных по результатам обра-
ботки заполненных ими контрольных списков. Ре-
зультаты вычисления апостериорных байесовских
оценок уровней выполнения практики SP 2.2 при-
ведены в таблице 4.
Полученная в примере апостериорная вероят-
ность гипотезы о том, что по результатам обследо-
вания практика SP 2.2 достигла третьего уровня ре-
ализации (PI, «частично выполнена»), гораздо
выше, чем вероятность истинности прочих гипо-
тез. Следующей по величине апостериорной веро-
ятности является гипотеза о выполнении практики
«в основном» (LI), вероятности же прочих гипотез
либо нулевые, либо почти равны нулю. Так как
предложенный метод рекомендуется в основном
для самооценки предприятия, заключением по ре-
зультатам данного оценивания может быть реше-
ние о том, что практику SP 2.2 можно считать реа-
лизованной.
Заключение
В статье предложено применение байесовского
подхода к оцениванию уровня выполнения прак-
тик, определенных в модели CMMI®. Данный под-
ход предполагает использование формулы Байеса
для построения распределения апостериорных ве-
роятностей на множестве гипотез о том, что сте-
Таблица 3
Пример расчета условных вероятностей соответствия свидетельств гипотезам Table 3
An example of calculation conditional probabilities of correspondence between evidence and hypotheses
NI
LI
Приведенные экспертные
оценки
NY
PI
FI
0
1
2
3
4
5
6
7
8
9
10
OE1 – п. 4.1.1.1 ТЗ АС
Э1
*
Э2
*
Э3
*
Э4
*
Э5
*
P(e1 | Hi)
1/5
3/5
0/5
3/5
1/5
OE2 – п. 4.1.8 ТЗ АС
Э1
*
Э2
*
Э3
*
Э4
*
Э5
*
P(e2 | Hi)
1/5
4/5
0/5
3/5
1/5
OE3 – п. 4.2.1 ТЗ АС
Э1
*
Э2
*
Э3
*
Э4
*
Э5
*
P(e3 | Hi)
1/5
4/5
0/5
3/5
1/5
OE4 – протокол первого совещания с заказчиком
Э1
*
Э2
*
Э3
*
Э4
*
Э5
*
P(e4 | Hi)
1/5
1/5
1/5
3/5
1/5
Программные продукты и системы / Software & Systems 1 (30) 2017
73
пень реализации рассматриваемой практики до-
стигла некоторого возможного уровня, исходя из
полученных результатов экспертного оценивания
имеющихся объективных свидетельств. Подход не
накладывает никаких ограничений на количество,
качество и конкретный перечень используемых
свидетельств, а также на состав оценивающей экс-
пертной группы и применим не только для специ-
фических практик процессных областей, но и для
общих практик при условии, что имеются объек-
тивные свидетельства, позволяющие произвести
экспертное оценивание. Для унификации результа-
тов экспертизы предлагается использование кон-
трольных списков, а для упрощения агрегации по-
лученных оценок и их пересчета в условные веро-
ятности гипотез – перевод всех оценок в единую
(например 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 Prod-
uct 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 с.
Таблица 4
Пример байесовской оценки уровня выполнения практики Table 4
An example of Bayesian estimate of a practice implementation level
Уровень выполнения практики
NY
NI
PI
LI
FI
Номер i-й гипотезы об уровне выполнения
1
2
3
4
5
Априорные вероятности P(Hi)
1/5
1/5
1/5
1/5
1/5
Оценки соответствия
гипотезам
P(e1 | Hi)
0
1/5
3/5
3/5
1/5
P(e2 | Hi)
0
1/5
3/5
4/5
1/5
P(e3 | Hi)
0
1/5
3/5
4/5
1/5
P(e4 | Hi)
1/5
1/5
3/5
1/5
1/5
Апостериорные вероятности
P(Hi | e1, e2, e3, e4)
0
0,01
0,62
0,36
0,01
Программные продукты и системы / Software & Systems 1 (30) 2017
74
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/lo
gic&methodology_dec07.pdf (дата обращения: 01.07.2016).
Software & Systems Received 15.07.16
DOI: 10.15827/0236-235X.117.067-074 2017, vol. 30, no. 1, pp. 67–74
USING BAYES' THEOREM TO ESTIMATE CMMI® PRACTICES IMPLEMENTATION
G.I. Kozhomberdieva 1, Ph.D. (Engineering), Associate Professor, kgi-liizht@yandex.ru
D.P. Burakov 1, Ph.D. (Engineering), Associate Professor, burakovdmitry8@gmail.com
M.I. Garina 1, Ph.D. (Engineering), Associate Professor, migarina@gmail.com
1 Petersburg State Transport University, Moskovsky Ave. 9, St. Petersburg, 190031, Russian Federation
Abstract. The article is devoted to the expert estimation methodology (based on objective evidence) for appraising the
extent of implementation of practices, which ensure achievement of the goals of CMMI® model process areas. The model has
been developed by the Software Engineering Institute (SEI) at Carnegie Mellon University. Such appraisals are necessary to
understand the software development processes maturity level in a developer company.
In case of uncertainty and/or incompleteness of information on CMMI® practice implementation, it is reasonable to use a
toolkit for decision-making in weakly formalized subject domains. It helps to increase a degree of belief to decisions of ap-
praisal team members. In the previously published work, the authors have considered two approaches to construction of the
estimation: fuzzy logic methods and multi-criteria classification methods.
This article makes an attempt to make the appraisal procedure even more simple and flexible, to expand the opportunities
for its use and to increase its objectivity. The proposed approach is based on the known Bayes' theorem. An extent of CMMI®
practice implementation is estimated via the distribution of probabilities on a set of hypothesizes. Each of hypotheses assumes
that an implementation level reached one of predefined ones. The Bayesian estimation of a practice implementation extent is
understood as a posteriori probability distribution, which is revised and refined during the estimation. Values of conditional
probability that are used when calculating the Bayesian estimation, show how much hypothesis on a practices implementation
level are supported by the obtained objective evidences.
Keywords: CMMI®, process area, capability levels, maturity levels, appraisement, objective evidence, decision theory,
Bayes' theorem, Bayesian approach, expert estimation.
Acknowledgements. The authors appreciate cooperation of Prof. A.E. Kraskovsky, who is a qualified specialist in the field
of control issues on railway transport. He suppors the idea of using Bayes' theorem when estimating the quality of management
decisions. We are also greatful to a chairman of the board of directors of Digital Design corporate group A.R. Fedorov and a
former head of the Department of IT development and corporate processes of Russian Railways A.V. Illarionov, who helped to
discover CMMI ® model. References
1. Ahern D.M., Clouse A., Turner R. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. Addison-Wesley
Prof. Publ., 2004, 305 p. (Russ.ed.: Moscow, MFK Publ., 2005, 330 p.).
2. CMMI® for Development, Version 1.3. (CMMI-DEV, V1.3). Improving processes for developing better products and services.
CMU/SEI-2010-TR-033. ESC-TR-2010-033. Software Engineering Institute, CMMI Product Team, 2010.
3. Appraisal Requirements for CMMI®, Version 1.2 (ARC, V1.2). CMU/SEI-2006-TR-011. ESC-TR-2006-011. Software Engineering
Institute, SCAMPI Upgrade Team, 2006.
4. Kozhomberdieva G.I., Garina M.I., Burakov D.P. Using decision making theory for appraisement problems according to the CMMI®
model. Programmnye produkty i sistemy [Software & Systems]. 2013, no. 4, pp. 117–124 (in Russ.).
5. Venttsel E.S., Ovcharov L.A. Teoriya veroyatnostey i ee inzhenernye prilozheniya [Theory of Probability and its Engineering Appli-
cations]. Moscow, Nauka Publ., 1988, 480 p.
6. Kozhomberdieva G.I., Kraskovsky A.E. Bayesian approach to control decision quality estimation. Intellektualnye sistemy na trans-
porte: mater. III mezhdunar. nauch.-praktich. konf. “IntellectTrans-2013” [Intelligent Systems on Transport: Proc. 3rd int. Science and Prac-
tice Conf. “IntellectTrans-2013”]. St. Petersburg State Transport Univ. Publ., 2013, pp. 384–391 (in Russ).
7. Kozhomberdieva G.I., Kraskovsky A.E A method of conditional probabilities determination for Bayesian control decision quality
estimation on transport. Intellektualnye sistemy na transporte: mater. IV mezhdunar. nauch.-praktich. konf. ”IntellectTrans-2014” [Intelligent
Systems on Transport: Proc. 4th Int. Science and Practice. Conf. “IntellectTrans-2014”]. St. Petersburg State Transport Univ. Publ., 2014,
pp. 412–418 (in Russ).
8. Leonenkov A.V. Nechetkoe modelirovanie v srede MATLAB i fuzzyTECH [Fuzzy Modeling in MATLAB and fuzzyTECH]. St. Pe-
tersburg, BHV-Peterburg Publ., 2005, 736 p.
9. Moiseev N.N. Matematicheskie zadachi sistemnogo analiza [Math Tasks of System Analysis]. Study guide. 2nd ed. Moscow,
LIBROKOM Publ., 2012, 488 p.
10. Kendall M. Rank Correlation Methods. 4th ed. Griffin, London, 1970.
11. Raiffa H. Decision Analysis: Introductory Lectures on Choices Under Uncertainty. Addison-Wesley Publ., Reading, MA, 1968.
12. Morris W. Management science: A Bayesian introduction. Prentice-Hall Publ., Enqlewood Cliffs, NY, 1968.
13. Utkin L.V. Analiz riska i prinyatie resheny pri nepolnoy informatsii [Risk analysis and decision making with incomplete information].
St. Petersburg, Nauka Publ., 2007, 404 p. (in Russ.).
14. Scriven M. The logic and methodology of checklists. 2000. Available at: http://www.wmich.edu/sites/default/files/attach-
ments/u350/2014/logic&methodology_dec07.pdf (accessed July 1, 2016).
ResearchGate has not been able to resolve any citations for this publication.
Article
Procedures for the use of the humble checklist, while no one would deny their utility, in evaluation and elsewhere, are usually thought to fall somewhat below the entry level of what we call a methodology, let alone a theory. But many checklists used in evaluation incorporate a quite complex theory, or at least a set of assumptions, which we are well advised to uncover— and the process of validating an evaluative checklist is a task calling for considerable sophistication. Interestingly, while the theory underlying a checklist is less ambitious than the kind that we normally call program theory, it is often all the theory we need for an evaluation. This memo covers some of the basic features of checklists and their application in evaluation, but it does not claim to exhaust their logic or methodology. Basic Concepts A checklist is taken here to be a list of factors, properties, aspects, components, criteria, tasks, or dimensions, the presence or amount of which are to be separately considered, in order to perform a certain task. There are many different types of checklist, although they have at least one nondefinitional function in common—that of being a mnemonic device. This function alone makes them useful in evaluation, since the nature of evaluation calls for a systematic approach to determining the merit, worth, etc., of what are often complex entities. Hence, a list of the many components or dimensions of performance of such entities is frequently valuable, and to judge from the results, even professional evaluators often forget key elements that should be included in systematic evaluations. Checklists are of various kinds: at the bottom of the checklist peck order, there is the eponymous laundry list, which is almost entirely a mnemonic device and nonetheless useful for that. Notice that the order in which one calls on the items on a laundry list does not affect its validity: we can just start by entering on the list whatever items are at the top of the laundry pile. But the entry of entities into the right category on the list is crucial—to avoid the equivalent of keyboarding errors in empirical data entry. And the grouping of items, when constructing the list, is often quite important, e.g., shirts with possibly bleeding colors need to be kept separate from white shirts. Of course, a real laundry list is not an evaluative list, but plenty of "laundry lists" are used in evaluation, and one of these is given later.
Article
Este libro tiene dos objetivos: primero, presenta una visión de la ciencia de la administración como una disciplina y una profesión, segundo, examina las posibilidades del uso de la lógica bayesiana como una estructura integral que ilumine la unidad entre algunas de las diversas ideas de la administración.
Теория вероятностей и ее инженерные приложения. М.: Наука
  • Е С Вентцель
  • Л А Овчаров
Вентцель Е.С., Овчаров Л.А. Теория вероятностей и ее инженерные приложения. М.: Наука, 1988. 480 с.
Teoriya veroyatnostey i ee inzhenernye prilozheniya
  • E S Venttsel
  • L A Ovcharov
Venttsel E.S., Ovcharov L.A. Teoriya veroyatnostey i ee inzhenernye prilozheniya [Theory of Probability and its Engineering Applications].
Анализ риска и принятие решений при неполной информации СПб: Наука, 2007. 404 с. 14. Scriven M. The logic and methodology of checklists
  • Л В Уткин
Уткин Л. В. Анализ риска и принятие решений при неполной информации. СПб: Наука, 2007. 404 с. 14. Scriven M. The logic and methodology of checklists. URL: http://www.wmich.edu/sites/default/files/attachments/u350/2014/lo gic&methodology_dec07.pdf (дата обращения: 01.07.2016).
Nechetkoe modelirovanie v srede MATLAB i fuzzyTECH [Fuzzy Modeling in MATLAB and fuzzyTECH
  • A V Leonenkov
Leonenkov A.V. Nechetkoe modelirovanie v srede MATLAB i fuzzyTECH [Fuzzy Modeling in MATLAB and fuzzyTECH].
Анализ решений (введение в проблему выбора в условиях неопределенности); [пер. с англ
  • Г Райфа
Райфа Г. Анализ решений (введение в проблему выбора в условиях неопределенности); [пер. с англ.]. М.: Наука, 1977. 408 с. 12. Моррис У.Т. Наука об управлении: байесовский подход; [пер. с англ.]. М.: Мир, 1971. 304 с.