|
p align="left">Таксономия риска обеспечивает систематизацию рисков по указанным в ней аспектам программной инженерии и служит основой для разработки методов идентификации источников риска путем интервьюирования членов проекта с использованием опросника, согласующегося с этой таксономией. Опросник, основанный на таксономии риска (для краткости, TBQ, от Taxonomy-Based Questionnaire), является инструментом, применение которого гарантирует охват всех потенциальных областей риска благодаря наличию в нем вопросов, касающихся нижнего уровня таксономии риска - атрибутов. Количество и форма задаваемых вопросов может быть различной в зависимости от специфики проекта, выбранного метода интервьюирования и обработки его результатов. В любом случае она должна ориентироваться на максимально полное и эффективное извлечение знаний членов проекта (включая менеджеров, проектировщиков, технический персонал и др.) о рисках конкретного проекта ПО. Таблица 3 - Список 10 главных программных рисков |
Программные риски | Техника управления рисками | | 1. Провалы персонала, плохой менеджмент | Поиск талантов; рабочее соревнование; построение команды; персональные договора; перекрестные тренировки; предопределение ключевых фигур. | | 2. Нереальные сроки и бюджеты, ошибки в планировании работ над проектом | Детализированный анализ стоимости и ожидаемых сроков; оценка стоимости; пошаговая разработка; повторное использование ПО; смягчение требований. | | 3. Разработка неправильных программных функций, ошибки проектирования системы | Организационный анализ; анализ задачи; формулирование условий; пользовательские обзоры; прототипирование; ранние пользовательские руководства. | | 4. Разработка ошибочного интерфейса пользователя, плохая связь с заказчиком | Прототипирование; сценарии; анализ задач; классификация пользователей (функциональная, стилевая, по загрузке). | | 5. Потеря прибыльности, неумение заключать договора, некачественное внедрение | Снижение требований; прототипирование; стоимостный анализ; оценка стоимости. | | 6. Неверно сформулированные требования или изменяющиеся требования | Высокий порог изменений; инкапсуляция информации; пошаговая разработка (откладывает изменения на дальнейшие шаги разработки). | | 7. Провалы во внешнем снабжении компонентами, неверный выбор коммерческого ПО | Тестирования; проверки; справочные проверки; анализ совместимости. | | 8. Провалы во внешне исполняемых задачах, недостаточное тестирование и плохая интеграция ПО | Справочные проверки; аудит; премиальные контракты; конкурентная разработка или прототипирование; построение команды. | | 9. Провалы производительности | Имитационное моделирование; тестирование; прототипирование; подгонка инструментария. | | 10. Превышение возможностей компьютерной науки | Технический анализ; анализ прибыльности; прототипирование; справочные проверки. | | |
2.3 Методология оценки и управления рискомИсследования риска - это длительный (несколько месяцев) процесс, в ходе которого предпринимаются совместные усилия ведущей организацией по вопросам управления риском (в рамках страны, определенной отрасли или государственной структуры) и организацией-клиентом:· по изучению существующей практики разработки конкретного проекта,· оценке альтернативных приемов управления риском,· выработке концепции управления риском клиента,· обучению методам управления риском· созданию необходимой инфраструктуры и плана управления риском ПО в организации-клиенте.Поскольку управление риском, отнесено к уровню 3 модели технологической зрелости организаций-разработчиков, оценка и управление риском - это достаточно отдаленная перспектива для отечественной программной инженерии.Процесс управления риском проекта ПО включает следующие четыре стадии:· согласование целей - определение нужд и целей проекта, достижение соглашений по управлению риском,· подготовка работ - планирование и координация предстоящих работ по оцениванию риска проекта ПО,· оценка риска - выполнение функций управления риском и получение рекомендаций по управлению риском проекта ПО,· подготовка к устранению риска - разработка рекомендаций по устранению рисков по всем областям устранения риска, разработка плана управления риском и приведение его в действие.Процесс управления риском применяется независимо от стадии ЖЦ, на которой находится проект ПО, и независимо от конкретного сценария и форм организации взаимодействия заказчика, исполнителя, соисполнителей и др. при разработке проекта. Разработано 3 методологии: оценивание риска ПО - SRE (от Software Risk Evaluation), непрерывное управление риском - CRM (от Continuous Risk Мanagement), коллективное управление риском - TRM (от Team Risk Management). 2.3.1 Оценивание риска ПО Методология SRE предлагает формальный метод идентификации, анализа, контроля и устранения риска ПО, который применяется первоначально на самой ранней стадии разработки проекта ПО (еще до заключения договора с разработчиком) и затем периодически в ходе всего ЖЦ проекта. Предлагаемые SRE функции управления риском подразделяются на основные и обеспечивающие. К основным функциям управления риском относятся: · обнаружение, · спецификация, · оценивание, · структурирование (консолидация) · устранение рисков. Выполнение функции обнаружения рисков обеспечивает систематический и полный охват всех потенциальных областей риска с применением адекватных инструментов и технологий, в частности, опросника TBQ. Выполнение функции спецификации риска касается фиксации всех аспектов идентифицированного риска ПО. Спецификация риска представляет собой структуру, которая упрощает решение задач приоритезации рисков, локализации источников и причин возникновения рисков, определения методов и усилий, предпринимаемых для устранения рисков в источниках их возникновения. Существует много способов спецификации риска - от простого утверждения о риске до сложного высказывания с применением условных выражений вида “ЕСЛИ <условие> ТО <последствия>”, связок “И” и др. Выбор того или иного способа определяется эффективностью его практического применения для проекта и особенностями инструментальной поддержки обработки рисков. Функция оценивания риска заключается в определении величины каждого риска ПО, что служит основанием для присваивания приоритета риску и выявления наиболее важных на текущий момент рисков проекта. Существуют различные механизмы оценивания величины риска - от простых субъективных оценок по 3-бальной шкале до строгих статистических измерений. Примеры простых механизмов оценивания величины риска представлены на рис. 2. Рис. 2. Матрица трехуровневой оценки риска Функция консолидации рисков касается преобразования разрозненных данных о каждом риске в концентрированные информационные блоки для принятия решений по управлению риском. Преобразование данных основано на применении приемов объединения, структурирования и абстракции данных об отдельных рисках ПО (что, например, необходимо, в случае обнаружения идентичных рисков в разных сеансах интервьюирования, различных проявлений одного и того же риска, поглощающих рисков от одного источника, рисков, мало отличающихся по величине, и др.). Функция устранения рисков состоит в определении областей проекта (областей устранения риска), на которых необходимо сосредоточить ресурсы, а также разработке стратегий и рекомендуемых действий, способных снизить и устранить угрозу успешного выполнения проекта. Область устранения риска представляет собой логическую группировку подобных рисков, удобную с точки зрения эффективного управления этими рисками. Результатом выполнения данной функции является план управления риском проекта ПО, а также элементы организационно-методической, технологической и инструментальной поддержки управления риском проекта ПО. Собственно устранение каждого риска осуществляется в соответствии с конкретным планом его устранения. К обеспечивающим функциям при оценивании риска относятся функции согласования действий по управлению риском, их планирования и координации, верификации и валидации, а также обучения и создания условий для эффективного ведения (хранения, обновления, удаления) информации о риске. Организации, в которых внедряется процесс управления риском проектов ПО, как правило разрабатывают собственный или адаптируют приведенный метод оценивания риска к потребностям и инфраструктуре собственных проектов. 2.3.2 Непрерывное управление риском Эта методология основана на определенных принципах управления риском в ходе всего ЖЦ проекта и не зависит от конкретных применяемых методов и инструментов оценки и устранения риска. Семь принципов управления риском таковы: Таблица 3 |
Принцип управления риском | Характеристика принципа управления риском | | 1. Разностороннее (в разных проекциях) видение предмета | Формирование взгляда на предмет с разных позиций при сохранении общности целей, коллективной ответственности и распределении обязанностей; концентрация внимания на результатах | | 2. Коллективная работа | Совместная работа для достижения общей цели; оптимальные условия проявления таланта, знаний и опыта | | 3. Глобальные перспективы | Восприятие разработки ПО в контексте крупномасштабных работ по проекту системы; допущение как благоприятных, так и неблагоприяных перспектив реализации спецификаций продукта ПО (связанных с превышением сроков, стоимости, программными сбоями и др.) | | 4. Дальновидность | Опережение событий, идентификация неопределенностей, предупреждение потенциальных проблем; управление проектными ресурсами и действиями в режиме предвосхищения проблем; | | 5. Открытое взаимодействие | Поощрение свободного тока информации между всеми уровнями проекта; обеспечение возможности формального, неформального и импровизированного взаимодействия; обеспечение процесса достижения консенсуса с учетом мнений отдельных лиц (имеющих специальные знания и углубленный взгляд на проблему идентификации и управления конкретным риском) | | 6. Интегрированное управление | Признание управления риском в качестве интегральной и жизненно важной части управления проектом; адаптация методов и инструментов управления риском к инфраструктуре и культуре проекта; | | 7. Непрерывность процесса | Постоянство бдительности; непрерывное идентифицирование и управление рисками на всех стадиях ЖЦ проекта | | |
2.3.3 Коллективное управление риском Эта методология определяет дополнительные действия в деятельности по управлению риском, которые связаны с осуществлением совместного управления риском со стороны заказчика проекта ПО и его исполнителя. Ее применение обеспечивает формирование среды, содержащей множество процессов, методов и инструментов, необходимых для совместной работы заказчика и исполнителя над непрерывным управлением риском в ходе ЖЦ проекта. Методология основана на семи принципах управление риском (п. 2.3.2.) и философии бригадной работы, к которым добавляет две функции - инициирование коллективной работы и собственно коллективное управление риском. Эти функции выполняются над каждым риском последовательно, но действия по управлению риском проекта в целом могут быть как последовательными, так и параллельными, и итеративными (например, планирование для одного риска может совмещаться с идентификацией другого). Инициировать коллективную работу может либо заказчик, либо исполнитель. При этом оба коллектива должны осознавать необходимость соблюдения принципов коллективной работы и ответственность за ее результаты. Коллективное управление предполагает формализацию отношений заказчик-исполнитель и формирование обобщенных взглядов на риски ПО. Систематическое и периодическое совместное применение методов управления риском обеспечивает единообразие в понимании рисков проекта и их относительной важности и получение обобщенной информации о рисках, приоритетах, метриках и планах действий.
Страницы: 1, 2, 3
|
