Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

474 Глава 10

персонал и др.) о рисках конкретного проекта ПС.

Обобщенный вариант TBQ института SEI использует определенные согла-

шения и правила задания и интерпретации ответов на вопросы (касающиеся

нумерации вопросов, их структуры и др.). В приложении 6 предлагается несколько

отличный от используемого SEI вариант TBQ, разработанный с учетом удобства

последующей автоматизации процесса интервьюирования и обработки ответов.

10.2. Обзор методологий управления риском проекта

10.2.1. Методология оценивания риска

SEI предлагает использовать три методологии управления риском ПС:

• оценивание риска,

• непрерывное управление риском,

• коллективное управление риском.

Методология оценивания риска SRE (от Software Risk Evaluation) включает

формальный метод идентификации, анализа, контроля и устранения рисков ПС,

который применяется первоначально на самой ранней стадии разработки проекта

ПС (еще до заключения договора с разработчиком) и затем периодически в ходе

всего ЖЦ проекта.

Предлагаемые SRE функции управления риском подразделяются на основ-

ные и обеспечивающие.

Основные функции. К основным функциям относятся обнаружение, специ-

фикация, оценивание, структурирование (консолидация) и устранение рисков.

Выполнение функции обнаружения рисков обеспечивает систематический и

полный охват всех потенциальных областей риска с применением адекватных ин-

струментов и технологий, в частности, вопросника TBQ.

Выполнение функции спецификации риска касается фиксации всех аспектов

идентифицированного риска ПС. Форма-спецификация риска представляет собой

структуру, которая упрощает решение задач приоритезации рисков, локализации

источников и причин возникновения рисков, определения методов и усилий, пред-

принимаемых для устранения рисков в источниках их возникновения.

Существует много способов спецификации риска - от простого утверждения

о риске до сложного высказывания с применением условных выражений вида

«ЕСЛИ <условие> ТО <последствия>», связок «И» и др. Выбор того или иного

способа определяется эффективностью его практического применения для кон-

кретного проекта и особенностями инструментальной поддержки обработки рис-

ков. Наряду с утверждением о риске в спецификации указывается источник риска,

ассоциированный с категорией (номером) риска по таксономии, и другая информа-

ция.

Функция оценивания риска заключается в определении величины каждого

риска, что служит основанием для присваивания приоритета риску и выявления

наиболее важных на текущий момент рисков проекта.

Существуют различные механизмы оценивания величины риска - от простых

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

Примеры простых механизмов оценивания величины риска представлены в

таблице 10.2 и на рисунке 10.4.

Глава 10 475

Таблица 10.2. Шкала для оценивания рисков

Величина

риска

Описание

Критический Высокая вероятность того, что есть серьезный риск для многих факто-

ров проекта ПС (стоимости, эффективности, сопровождаемости и др.).

Высокий Высокая вероятность того, что есть умеренный риск для одного или

более факторов проекта.

Средний Средняя вероятность того, что есть умеренный риск для одного или бо-

лее факторов проекта.

Низкий Низкая вероятность того, что есть умеренный риск для одного из мно-

гих факторов проекта.

Очень

возможно

Возможно Невозможно

Катастрофи -

ческие

Критические

Приемлемые

Низкий

Высокий

Средний

Серьезность

последствий

Вероятность

Рис.10.4. Матрица трехуровневой оценки риска

Функция консолидации рисков касается преобразования разрозненных дан-

ных о каждом риске в концентрированные информационные блоки для принятия

решений по управлению риском. Преобразование данных основано на применении

приемов объединения, структурирования и абстракции данных об отдельных рис-

ках ПС (что, например, необходимо, в случае обнаружения идентичных рисков в

разных сеансах интервьюирования, различных проявлений одного и того же риска,

поглощающих рисков от одного источника, рисков, мало отличающихся по вели-

чине, и др.).

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

торых необходимо сосредоточить ресурсы (и называемых областями устранения

риска), а также разработке стратегий и рекомендуемых действий, способных сни-

зить и устранить угрозу успешного выполнения проекта. Область устранения рис-

ка представляет собой логическую группировку подобных рисков, удобную с точ-

ки зрения эффективного управления этими рисками. Результатом выполнения дан-

ной функции является план управления риском проекта ПС, а также элементы ор-

ганизационно-методической, технологической и инструментальной поддержки

управления риском проекта ПС.

476 Глава 10

Собственно устранение каждого риска осуществляется в соответствии с кон-

кретным планом его устранения и поддерживается такими функциями парадигмы

управления риском, как планирование, учет, контроль и регулирование риска.

Обеспечивающие функции. К обеспечивающим функциям при оценивании

риска, предлагаемым методологией SRE, относятся функции согласования дейст-

вий по управлению риском, их планирования и координации, верификации и вали-

дации, а также обучения и создания условий для эффективного ведения (хранения,

обновления, удаления) информации о риске.

Организации, в которых внедряется процесс управления риском проектов

ПС, как правило разрабатывают собственный или адаптируют приведенный метод

оценивания риска к потребностям и инфраструктуре собственных проектов. Неко-

торые практические предложения по оцениванию риска разработки отечественных

проектов представлены в разделе 10.5.

10.2.2. Непрерывное управление риском

Методология непрерывного управления риском CRM (от Continuous Risk

Мanagement) основана на определенных принципах управления риском в ходе все-

го ЖЦ проекта и не зависит от конкретных применяемых методов и инструментов

оценки и устранения риска. Принципы управления риском таковы:

• разностороннее (в разных проекциях) видение предмета

- формирование взгляда на предмет с разных позиций при сохранении

общности целей, коллективной ответственности и распределении обя-

занностей;

- концентрация внимания на результатах;

• коллективная работа

- совместная работа для достижения общей цели;

- оптимальные условия проявления таланта, знаний и опыта;

• глобальные перспективы

- восприятие разработки ПС в контексте крупномасштабных работ по

проекту системы;

- допущение как благоприятных, так и неблагоприятных перспектив

реализации спецификаций ПС (связанных с превышением сроков,

стоимости, программными сбоями и др.);

• дальновидность

- опережение событий, идентификация неопределенностей, предупреж-

дение потенциальных проблем;

- управление проектными ресурсами и действиями в режиме предвос-

хищения проблем;

• открытое взаимодействие

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

екта;

- обеспечение возможности формального, неформального и импрови-

зированного взаимодействия;

Глава 10 477

- обеспечение процесса достижения консенсуса с учетом мнений от-

дельных лиц (имеющих специальные знания и углубленный взгляд на

проблему идентификации и управления конкретным риском);

• интегрированное управление

- признание управления риском в качестве интегральной и жизненно

важной части управления проектом;

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

туре и культуре проекта;

• непрерывность процесса

- постоянство бдительности;

- непрерывная идентификация и управление рисками на всех стадиях

ЖЦ проекта.

На этих принципах основаны базовые функции управления риском - иденти-

фикация, анализ, планирование, учет и контроль, регулирование и коммуникация,

которые детально описаны в разделе 10.4.

10.2.3. Коллективное управление риском

Методология коллективного управления риском TRM (от Team Risk Man-

agement) определяет дополнительные действия в деятельности по управлению рис-

ком, которые связаны с осуществлением совместного управления риском со сто-

роны заказчика проекта ПС и его исполнителя. Ее применение обеспечивает

формирование среды, содержащей множество процессов, методов и инструментов,

необходимых для совместной работы заказчика и исполнителя над непрерывным

управлением риском в ходе ЖЦ проекта.

Методология TRM основана на семи рассмотренных выше принципах управ-

ления риском и философии бригадной (групповой) работы. Она развивает пара-

дигму управления риском, предложенную SEI, путем добавления двух функций -

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

ком. Эти функции выполняются последовательно применительно к каждому риску,

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

ными, так и параллельными, и итеративными (например, планирование для одного

риска может совмещаться с идентификацией другого).

Инициировать коллективную работу может либо заказчик, либо исполни-

тель. При этом оба коллектива должны осознавать необходимость соблюдения

принципов коллективной работы и ответственность за ее результаты.

Коллективное управление предполагает формализацию отношений заказчик-

исполнитель и формирование обобщенных взглядов на риски ПС. Систематическое

и периодическое совместное применение методов управления риском обеспечивает

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

ние обобщенной информации о рисках, приоритетах, метриках и планах действий.

Основные положения трех методологий, представленных выше, послужили

базисом для формирования подхода к управлению риском проектов ПС в терминах

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

ния, а также необходимой инструментальной поддержки модели принятия решений

при оценивании риска.

478 Глава 10

10.3. Процесс управления риском проекта

10.3.1. Требования к процессу управления риском

В стандарте ISO/IEC 12207 указывается, что «назначение процесса управле-

ния риском состоит в непрерывной идентификации и уменьшении рисков проекта в

течение всего жизненного цикла проекта. В результате успешного осуществления

процесса:

• будет определена сфера управления риском;

• будут определены и внедрены надлежащие стратегии управления рис-

ком;

• кроме рисков проекта, оговоренных в стратегии управления риском про-

екта, будут идентифицироваться риски, возникающие в ходе выполнения проекта;

• риски будут анализироваться, и ресурсы для мониторинга этих рисков

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

• методы мониторинга риска будут выбираться таким образом, чтобы была

возможность выявлять изменения в состоянии риска и контролировать действия по

мониторингу;

• будут приниматься надлежащие меры по устранению и предупреждению

влияния риска» [3].

Нужно отметить, что процесса управления риском не было среди процессов

ЖЦ в первой редакции стандарта ISO/IEC 12207:1995, и его появление в проекте

новой версии стандарта свидетельствует о признании важности проблемы управле-

ния риском проекта для разработки высококачественных систем. Концепция не-

прерывности управления риском, лежащая в основе парадигмы SEI, позволяет по-

строить процесс управления риском, соответствующий требованиям стандарта

ISO/IEC 12207.

Процесс управления риском проекта ПС, предлагаемый SEI, включает сле-

дующие четыре этапа [4]:

• согласование целей - определение нужд и целей проекта, достижение со-

глашений по управлению риском,

• подготовка работ - планирование и координация предстоящих работ по

оцениванию риска проекта ПС,

• оценивание риска - выполнение функций SRE и получение рекомендаций

по управлению риском проекта ПС,

• подготовка к устранению риска - разработка рекомендаций по устране-

нию рисков по всем областям устранения риска,

• разработка плана управления риском и приведение его в действие.

Процесс управления риском применяется независимо от стадии ЖЦ, на кото-

рой находится проект, и независимо от конкретного сценария и форм организации

взаимодействия действующих лиц при разработке проекта - заказчика, исполните-

ля, соисполнителей, сторонних экспертов и др.

Один из возможных примеров использования процесса управления риском

представлен на рисунке 10.5.

Глава 10 479

Организации-

пользователи

Руководство

программой

Проект ПС

Организация-заказчик Организация-разработчик

Несет ответственность за приобретение продуктов ПС

Независимая группа SRE

Итоговый отчет

Запрос на оценку риска

Функции SRE

Информация о рисках

Данные для проведения

брифингов

Управление

риском

Рис. 10.5. Пример применения процесса управления риском

В этом примере заказчиком проекта ПС, в разработке которой заинтересова-

на широкая общественность, является государственная организация-посредник,

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

ектов. Эта организация заключает договор с определенной организацией-

разработчиком на выполнение проекта. Далее, для внедрения процесса управления

риском и выполнения оценок риска срыва этого проекта она обращается к незави-

симой организации, оказывающей услуги по управлению риском проектов, и нани-

мает независимую группу экспертов, становясь ее клиентом.

Независимая группа выполняет функции SRE (см. п.10.2.1), обеспечивает

подготовку и проведение брифингов и совещаний по оценке риска на территории

организации-разработчика и анализ полученной информации о рисках. Совместно с

заинтересованными организациями независимая группа разрабатывает стратегии

устранения риска и составляет рекомендации по управлению риском с учетом осо-

бенностей конкретного проекта.

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

ту. Этот отчет содержит описание всех найденных рисков и предложения по их

устранению.

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

ганизацией-исполнителем составляет план управления риском проекта ПС (п.10.3.8)

и в дальнейшем периодически контролирует его выполнение.

Организация-разработчик обеспечивает выполнение функций учета, контро-

ля и регулирования указанных в отчете рисков по соответствующим частным пла-

нам устранения риска для каждого риска (или группы рисков из одной области

риска). План устранения риска разрабатывается для наиболее важных рисков, уста-

новленных в процессе идентификации и анализа рисков.

Группа проекта в ходе процессов учета и контроля риска должна отслежи-

вать с одной стороны выполнение плана устранения риска, а с другой - его эффек-

480 Глава 10

тивность в снижении конкретного риска. Если план не выполняется, он может быть

заменен новым планом, либо в действие может быть введен заранее подготовлен-

ный альтернативный план выхода из исключительных ситуаций. Если план устра-

нения риска успешно выполнен - риск можно считать закрытым.

Закрытый риск удаляется из списка наиболее важных рисков, а его место в

списке занимается следующим риском, который получает статус важного риска с

определенным приоритетом.

Для нового риска составляется план устранения и этот риск включается в

сферу управления риском.

Клиентом независимой организации, оказывающей услуги в управлении рис-

ком, может стать не только организация-заказчик, но и организация-разработчик

ПС, если эта организация по собственной инициативе внедряет процесс управления

риском, стремясь усовершенствовать процесс разработки ПС.

Процесс управления риском проекта ПС начинается с осознания руково-

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

ординационной группы (совета) по управлению риском проекта. Численность

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

ких человек с полной занятостью. Кандидатами в координационную группу могут

быть члены группы проекта, представители пользователей, исполнителей и соис-

полнителей. Лидером этой группы является представитель нанимаемой независи-

мой группы экспертов, который несет ответственность за выполнение обеспечи-

вающих функций планирования и координации в рамках метода SRE. Интерфейс

организации-разработчика с независимой группой (в лице ее лидера) осуществля-

ется координатором действий из организации-разработчика. Он несет ответствен-

ность за подбор (в среде проекта) специалистов для интервьюирования и проведе-

ние брифингов при посещении организации-разработчика независимой группой

экспертов.

Собственно деятельность по управлению риском проекта ПС должна осуще-

ствляться квалифицированным персоналом, включенным в состав проекта (группой

проекта), а распределение ролей и ответственности за управление риском - отра-

жаться в плане управления риском. Один из возможных способов распределения

ответственности при управлении риском представлен на рисунке 10.6.

В данном примере каждый член группы несет ответственность за непрерыв-

ный процесс идентификации, оценивания и классификации рисков и формирование

планов устранения рисков. Утверждают эти планы технические лидеры группы

проекта. Ответственность за отслеживание состояния рисков проекта может быть

возложена и на отдельное лицо или группу лиц в проекте.

Менеджер проекта производит ревизию и интеграцию информации о рис-

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

взаимодействия с внешним окружением проекта.

Группа проекта периодически предоставляет отчеты о своей деятельности

руководству организации-заказчика. Эти результаты касаются состояния группы

рисков наибольшей важности (например, первой десятки или, в общем случае, пер-

вой Н-ки рисков) и планов по их устранению. Кроме того, предоставляется инфор-

мация об эффективности процесса управления риском (например, данные об ин-

тенсивности идентификации новых рисков по отношению к интенсивности устра-

Глава 10 481

нения рисков и др.). Детальная ревизия этой информации производится менедже-

ром проекта на периодической и событийной основе.

Идентификация

Учет и контроль

(трассировка)

Регулирование

- ревизия

- интеграция групп

Первая N-ка

рисков

Менеджер

проекта

Технические

лидеры

Анализ

- ревизия

- приоритезация

- оценивание

- классификация

Члены

группы

Риски

Планирование

- утверждение плана

- рекомендованные

планы

Состояния/

предсказания

Состояния/отклонения

Требуемые

метрики

Распределение

ответственности

Рис. 10.6. Распределение ролей при управлении риском

Лица, осуществляющие функции управления риском проекта ПС, должны

обладать знаниями в области программной инженерии, проблемной области, для

которой разрабатывается ПС, а также знать принципы управления риском и вла-

деть методами и инструментами управления риском.

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

риском, если:

• он принимал участие в управлении, по крайней мере, одним проектом,

• применял методологии управления риском, по крайней мере, для одного

проекта и

• имеет опыт в соответствующей проблемной области проекта.

Если не выполняется хотя бы одно из перечисленных условий, член группы

проекта должен иметь возможность пополнить свои знания путем обучения.

Способы приобретения необходимых знаний таковы:

• формальное обучение. Занятия с членами проекта проводятся организа-

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

• неформальное обучение. Этот вид обучения предполагает самостоятель-

ное посещение курсов или обучение по месту работы по соответствующей про-

грамме.

10.3.2. Этап согласования целей

На этапе согласования целей проводится не менее двух совещаний, по ре-

зультатам которых заключается соглашение с организацией-разработчиком на вы-

полнение оценки риска проекта ПС.

На первом совещании, проводимом высшим руководством организации-

разработчика совместно с лидером независимой группы экспертов (из независимой

482 Глава 10

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

ленные цели проекта и возможности их достижения.

В результате совещания:

• должны быть определены функции всех групп, представители которых

принимают участие в совещании;

• группа проекта должна получить достаточное представление о целях и

задачах SRE и быть способной определить контекст применения SRE в своем про-

екте;

• независимая организация-эксперт должна хорошо понять стратегический

контекст оценивания и получить ответы на вопросы о том, с какими стратегиче-

скими проблемами сталкивается организация? Каковы отдаленные перспективы

завершения проекта? Каковы ожидаемые результаты оценивание риска? Каковы

ближайшие перспективы организации? Какова степень критичности оценивания

риска? Каким рискам подвергается проект с точки зрения менеджеров? Каковы

оценки времени их перерастания в проблемы? Какого рода действия планирует ру-

ководство в связи с отмеченными рисками?

• независимая организация-эксперт и бригада проекта должны взвесить

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

нию работ и потребность в согласовании своих действий с высшим руководством

организации;

• должна быть назначена дата второго совещания.

Целью второго совещания является получение заключений и утверждение

договоренностей о проведении оценивания риска ПС. Наряду с участниками перво-

го совещания на второе совещание должны быть приглашены группы технической

поддержки из организации-разработчика.

На этом совещании рассматриваются проблемы, с которыми может столк-

нуться разработчик проекта, и подвергаются ревизии уже утвержденные цели про-

екта в части оценки риска. Здесь также поднимаются вопросы обеспечения ресур-

сами процедур управления риском.

В результате совещания:

• представители организации-разработчика должны понимать, в чем за-

ключается SRE, как долго выполняется оценка риска, каковы ресурсы, роли и ти-

пичные результаты проведения SRE, каковы требования к конфиденциальности

информации о рисках;

• независимая организация-эксперт должна понимать все проблемы клиен-

та, связанные с угрозами проекту, и должна разрешать те из них, которые касаются

оценивания риска;

• независимая организация-эксперт должна четко понимать, какие цели

преследует клиент, проводя оценивание риска, каков контекст оценивания в тер-

минах стратегических направлений и целей организации-разработчика;

• клиент и независимая организация-эксперт должны достичь соглашения

по вопросам логистики SRE: определить сроки и необходимые ресурсы, утвердить

координатора и т.д.;

• клиент должен осознать важность роли координатора;

• должен быть определен следующий шаг процесса управления риском.

Глава 10 483

10.3.3. Этап подготовки работ

Этап подготовительных работ состоит в адаптации метода оценивания риска

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

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

интервьюирование, и планировании оценивания риска.

Проведение подготовки к оцениванию риска возлагается на лидера незави-

симой группы экспертов и координатора (со стороны организации-разработчика).

Цель адаптации метода SRE к особенностям и целям проекта ПС состоит в

том, чтобы обеспечить эффективное применение предлагаемых SRE средств в ус-

ловиях среды разработки проекта. Адаптация предполагает соотнесение целей ор-

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

дущем этапе, определение вида и числа групп, которые должны интервьюировать-

ся, и приведение TBQ в соответствие с целями проекта.

Независимая группа управления риском комплектуется из 3 - 4 экспертов из

независимой организации, оказывающей услуги в управлении риском, и 2 - 3 чело-

век из организации-клиента, непосредственно не связанных с разрабатываемым

проектом. Участники группы со стороны организации-клиента не должны иметь

отношений подчиненности с интервьюируемыми лицами и не должны вовлекаться

в повседневную деятельность по разработке проекта. Однако они должны обладать

надлежащими знаниями организационных, технических и финансовых аспектов

проекта, а также иметь представление о процессе разработки ПС, используемых

технологиях и прикладной области проекта. Независимая группа должна пройти

формальное обучение до того, как приступит к исполнению обязанностей по управ-

лению риском проекта ПС. Ответственность за подбор группы и распределение

обязанностей в ней несет лидер группы.

Интервьюируемые группы могут формироваться исходя из различных крите-

риев, например, по принадлежности к организации или сфере деятельности, в кон-

тексте определенного класса продуктов, по спектру заказчиков или исполнителей

проекта, а также в разрезе функций разработки ПС. Обычно формируются сле-

дующие группы интервьюирования:

• группа, включающая аналитиков, проектировщиков, тестировщиков,

• группы различной профессиональной (функциональной) ориентации: не-

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

рацией и др.,

• группа менеджеров проекта ПО системы,

• группа инженеров-системотехников и программистов,

• группа заказчиков и пользователей,

• группа соисполнителей проекта и др.

Все члены одной группы интервьюирования не должны иметь отношений

подчиненности, что даст им возможность свободно излагать свои мысли по поводу

рисков, проблем и особенностей проекта. Обычная численность группы интер-

вьюирования – 5 - 6 человек. Ответственность за ее формирование и функциониро-

вание при проведении сеансов интервьюирования несет координатор, работающий

под руководством лидера независимой группы экспертов и использующий в своей

работе инструктивно-методические материалы этой группы.