Записаться

Презентация к части 4: ИТ-Процессы-4

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

1. Почему важны стандарты менеджмента качества и рисков

Управление качеством и управление рисками (risk management) — важные области менеджмента. В них есть практические референтные модели. Стандарты управления качеством, от ISO 9001 (ИСО 9001) до ISO/IEC 12207 (ИСО/МЭК 12207) и стандартов SQuaRE (Software product Quality Requirements and Evaluation), опираются на общие принципы. Это не разрозненные документы, а согласованные комплексы.

Управление рисками также описывается набором стандартов. Стандарты ISO задают фундамент; большинство методик и фреймворков опираются на них и не отрицают их. Поэтому эти стандарты нужно знать.

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

Применение методов менеджмента риска в процессах жизненного цикла ПО опирается как минимум на четыре международных стандарта, переведённых на русский язык. Они объединены серией «Менеджмент риска»: принципы и руководства, термины и определения, формальный анализ проекта, методы оценки риска. В них рассматриваются разные аспекты управления рисками. На их основе построен стандарт адаптации методов, идей и подходов к разработке ПО.

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

3. Версии, переводы и практические последствия

Русскоязычные переводы могут отставать. Новый аутентичный стандарт ISO, соответствующий последней версии, ссылается на актуализированные стандарты, которых на русском ещё нет. Ссылка «повисает в воздухе».

Пример: ISO/IEC 12207:2017 уже существует, но в переводах используется версия 2008 года, отменённая ISO. Новые переводы могут ссылаться на устаревшую версию. Перевод стандарта — небыстрый процесс, поэтому возникает лаг.

Если в русскоязычных версиях одно понятие определяется по-разному, это признак того, что переводы соответствуют не последним версиям, а смеси версий. Это затрагивает даже основное определение риска: в одном стандарте оно не совпадает с определением в более старом стандарте метода оценки риска.

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

По стандарту управления рисками процесс состоит из стандартных шагов: планирование, анализ, обработка, мониторинг и оценка процесса.

4.1 Планирование риска

Планирование — установление процесса менеджмента риска. Нужно создать процесс или адаптировать корпоративный процесс к ситуации с рисками ПО. Если корпоративного процесса нет, процесс менеджмента риска ПО существует отдельно.

Задачи:

• установить политику в области менеджмента риска;
• распределить обязанности;
• обучить персонал;
• выделить ресурсы;
• создать процесс в соответствии с политикой;
• описать процесс и довести описание до заинтересованных сторон.

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

Для проекта формируются хронологические данные о видах риска и способах обработки — управление профилем риска проекта (project risk profile). Профиль содержит совокупный риск проекта, профили индивидуальных рисков по задачам и записи о статусе риска.

4.2 Анализ, обработка и мониторинг риска

Анализ риска включает идентификацию событий, опасностей, угроз и вероятности возникновения риска.

Обработка риска — принятие мер. Типовые меры: принятие риска, уклонение от риска, передача риска.

Мониторинг риска — анализ, актуализация индивидуального риска и оценка результативности.

В конце процесса выполняется оценка процесса.

5. Специфика ИТ и практический вывод

В описании управления рисками для создания программных продуктов нет ИТ- или ПО-специфики. Так можно анализировать любой риск: идентифицировать исходное событие, опасности и угрозы, оценить вероятность, проверить индивидуальный риск или комбинацию рисков, выбрать альтернативные варианты обработки.

Зачем выделять этот процесс в отдельный документ для ИТ — неясно. Вероятно, документ подготовлен для единообразия. Он опирается на вышестоящие стандарты, но не содержит определений и точных описаний. Лучше читать основополагающие верхние стандарты, где всё подробно и с примерами, и самостоятельно применять их к ИТ, чем буквально воспроизводить бессодержательные тексты.

Краткие итоги

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

Логика процесса управления рисками показывает, что устойчивость даёт не отдельный анализ угроз, а связка планирования, анализа, обработки, мониторинга и оценки процесса. Планирование определяет правила игры, анализ выявляет неопределённость, обработка выбирает стратегию, мониторинг отслеживает изменение ситуации, а оценка процесса замыкает цикл обратной связью. Профиль риска проекта превращает разовые решения в накопляемую память: видно, какие риски были, как их обрабатывали и что изменилось.

Отсутствие ИТ-специфики в общем описании не означает, что ИТ-риски не имеют особенностей. Оно означает, что базовая модель универсальна, а отраслевая конкретика появляется на уровне активов, угроз, уязвимостей, метрик и критериев допустимости. Практический вывод: нужно уметь применять общую рамку к конкретной среде, а не подменять анализ формальным воспроизведением производных документов. Ценность даёт не сам текст стандарта, а способность адаптировать его принципы к реальным решениям, ограничениям и целям проекта.