|
p align="left">Основные положения трех методологий, представленных выше, послужили базисом для формирования подхода к управлению риском проектов ПО в терминах процесса управления риском, его оргструктуры и стадий выполнения, а также необходимой инструментальной поддержки модели принятия решений при оценивании риска. Один из возможных примеров использования процесса управления риском представлен на рис. 3. Рис. 3. Пример применения процесса управления риском 3. Организационная структура управления риском Процесс управления риском проекта ПО начинается с создания координационной группы (совета) по управлению риском проекта. Численность группы может колебаться от одного человека с частичной занятостью до нескольких человек с полной занятостью. Кандидатами в координационную группу могут быть члены бригады проекта, представители пользователей, исполнителей и соисполнителей. Лидером этой группы является представитель нанимаемой независимой группы экспертов, который несет ответственность за выполнение обеспечивающих функций планирования и координации в рамках метода SRE. Интерфейс организации-разработчика с независимой группой (в лице ее лидера) осуществляется координатором действий из организации-разработчика. Он несет ответственность за подбор (в среде проекта) специалистов для интервьюирования и проведение брифингов при посещении организации-разработчика независимой группой экспертов. Собственно деятельность по управлению риском проекта ПО должна осуществляться квалифицированным персоналом, включенным в состав проекта (бригадой проекта), а распределение ролей и ответственности за управление риском - отражаться в плане управления риском. Один из возможных способов распределения ответственности при управлении риском представлен на рис. 4. В данном примере каждый член бригады несет ответственность за непрерывный процесс идентификации, оценивания и классификации рисков и формирование планов устранения рисков. Утверждают эти планы технические лидеры бригады проекта. Ответственность за отслеживание состояния рисков проекта может быть возложена и на отдельное лицо или группу лиц в проекте. Менеджер проекта производит ревизию и интеграцию информации о рисках, назначение ответственных за риски и планы устранения, а также обеспечивает взаимодействия с внешним окружением проекта. Бригада проекта периодически предоставляет отчеты о своей деятельности руководству организации-заказчика. Эти результаты касаются состояния группы рисков наибольшей важности (например, первой десятки или, в общем случае, первой Н-ки рисков) и планов по их устранению. Кроме того, предоставляется информация об эффективности процесса управления риском (например, данные об интенсивности идентификации новых рисков по отношению к интенсивности устранения рисков и др.). Детальная ревизия этой информации производится менеджером проекта на периодической и событийной основе. Рис. 4. Распределение ролей при управлении риском Лица, осуществляющие функции управление риском проекта ПО, должны обладать знаниями в области программной инженерии, проблемной области, для которой разрабатывается ПО, а также знать принципы управления риском и владеть методами и инструментами управления риском. Считается, что человек обладает необходимыми знаниями для управления риском, если: · он принимал участие в управлении по крайней мере одним проектом, · применял методологии управления риском по крайней мере для одного проекта и · имеет опыт в соответствующей проблемной области проекта. Если не выполняется хотя бы одно из перечисленных условий, член проекта должен иметь возможность пополнить свои знания путем обучения. Способы приобретения необходимых знаний таковы: · формальное обучение. Занятия с членами проекта проводятся организацией-заказчиком или независимой организацией по соответствующей программе; · неформальное обучение. Этот вид обучения предполагает самостоятельное посещение курсов или обучение по месту работы по соответствующей программе. 4. Разработка плана управления риском Управление риском конкретного проекта ПО осуществляется в соответствии с планом управления риском, составленным с учетом рекомендаций, полученных от независимой группы экспертов и зафиксированных в итоговом отчете о проведении оценки риска проекта ПО. План управления риском проекта ПО определяет, каким образом процесс управления риском будет выполняться в рамках конкретного проекта разработки ПО, и указывает процессы, действия, этапы работ, методы и инструменты, используемые членами бригады проекта, ответственными за управление риском проекта ПО. Этот план может быть частью плана управления риском системного уровня, частью плана управления проектом или самостоятельным планом. Выбор того или иного способа планирования зависит от объема и сложности проекта, состава и размеров бригады проекта, а также общих принципов планирования, которым следует организация, осуществляющая управление риском. План управления риском может подвергаться модификации при появлении новых инструментов, методов или других элементов управления риском, необходимых для управления риском конкретного проекта. Текущий список рисков и планы по их устранению не рекомендуется включать в план управления риском проекта ПО, чтобы не пришлось непрерывно его корректировать. Рис. 5. Блок-схема принятия решения при планировании устранения риска Таблица 4 Рекомендации по содержанию плана управления риском |
Раздел плана управления риском | Описание | | Введение | Определяет цели и сферу действий плана, его содержание. Здесь должны быть указаны любые предположения, ограничения и принципы реализации процессов, а также любые связанные с этим планы, документы и стандарты. | | Обзор процессов | Краткое описание действий по управлению риском и их взаимосвязь. Определяются все потоки управления и данных, указывается, каким образом действия по управлению риском интегрируются с другими действиями по управлению проектом. | | Организация | Включает информацию об организации работ по управлению риском проекта и распределении ответственности (обязанностей) в проекте между заказчиком, поставщиком ПО (головным исполнителем) и соисполнителями. Указывается оргструктура управления риском, которая проецирует действия по управлению риском на роли, исполняемые членами проекта по управлению риском. Определяется перечень лиц, ответственных за управление риском со стороны организации-заказчика, организации-разработчика и организаций-соисполнителей, а также перечень выполняемых ими действий (процедур) и описание конкретных ожидаемых результатов этих действий. | | Детали процесса | В этом разделе подробно описываются процессы и процедуры, необходимые для систематического управления риском. Эта часть плана также включает: 1) методы и инструменты, которые выбираются для поддержки каждой функции, а также критерии их выбора; 2) ссылки на другие планы, руководства и учебные материалы по любому методу или инструменту, который документирован в другом месте (например, в соответствующих документах проекта, документах уровня организации или документах заказчика); 3) все показатели (метрики) улучшения процесса, которые должны собираться и фиксироваться в отчетах (например, число открытых рисков, число рисков по классам, тренд (изменения) величины риска от момента его идентификации до закрытия, число успешных устранений, число неуспешных устранений и др.); 4) процесс, обеспечивающий оценивание и улучшение основного процесса управления риском (например, ежеквартальное оценивание эффективности применяемых методов, периодическая ревизия отчетов заказчика с целью определения их полезности и др.). | | Ресурсы и графики | Этот раздел документирует ресурсы (например, стоимость, трудоемкость, оборудование и расходные материалы, используемое ПО), необходимые для поддержки процесса управления риском. Специфицируется утвержденный бюджет, а также источники финансирования устранения риска. В этот раздел плана включается проекция действий по управлению риском на план-график и этапы разработки проекта ПО, а также перечень всех выпускаемые рабочих продуктов, касающиеся управления риском, включая итоговые отчеты по риску, планы устранения и др. | | Документирование риска | В этом разделе должна быть специфицирована инструментальная поддержка управления риском, указаны структуры баз данных о рисках, методы, средства и процедуры ведения баз данных, перечень входных и отчетных форм и др. Здесь также должны быть определены все процедуры и требования по составлению, обработке, контролю и ведению (хранению) относящихся к риску документов и форм. | | |
5. Рекомендации по оценке риска проектов ПОАнализ методологий оценки риска, предлагаемых такими зарубежными организациями, как NASA Lewis Research Center, Defense Systems Management College, DSDC (Defense Logistics Agency Systems Design Center), BMPC (Best Manufacturing Practices Center), SEI и др. показал, что все они схожи в подходах к оцениванию риска, расходятся в принципах ранжирования рисков и в целом основываются на предложенной SEI таксономии риска, модифицируя перечень вопросов TBQ и меняя их форму.Вопросник содержит несколько вопросов к одному атрибуту таксономии, способных прояснить угрозы качеству, стоимости и срокам разработки продукта, которые связаны с указанным атрибутом.Каждому вопросу приписан максимальный вес, отражающий важность данного вопроса для снижения общего риска по соответствующему атрибуту. Чем выше вес, тем существеннее вопрос с точки зрения обнаружения риска.Вопросы для проведения интервьюирования сформулированы в такой форме, чтобы на каждый из них можно было дать однозначный ответ: “Да”, “Нет”, “Частично”, “Не знаю”, или “Не применим”.Ответ “Да” свидетельствует об отсутствии риска, суть которого сформулирована в вопросе. Ответ “Нет” или “Не знаю” свидетельствует о наличии риска. Ответ “Частично” также свидетельствует о наличии риска, но дает возможность эксперту, оценивающему риск, указать вес вопроса, отличный от предлагаемого максимального веса. Ответ “Не применим” соответствует неправомерности задания вопроса для данного проекта и не учитывается при оценке риска.Оценка риска выполняется снизу-вверх по каждому атрибуту таксономии с последующим вычислением комбинированного риска по элементам и классам.Метод оценки риска BMPC включает следующие шаги:1. Вычисление ранга риска R по одному атрибуту. Ранг риска атрибута R вычисляется исходя из количества вопросов, на которые был дан ответ “Да” или “Частично”. Определяется сумма весов этих ответов. Затем вычисляется общая сумма весов всех вопросов для атрибута (вес атрибута), за исключением вопросов с ответами “Не применим”. После этого находится процентное соотношение этих сумм по следующей формулеR = (i=1,k Vдi / (j=1,n Vi - j=1,t Vнi))*100,где Vдi - вес вопроса с ответом “Да” или “Частично”, к - количество таких ответов,Vi - вес каждого вопроса, n - общее количество вопросов в атрибуте;Vнi - вес вопроса с ответом “Не применим”, t - количество таких ответов.2. Вычисление уровня риска атрибута U.Если ранг риска R = 100%-70%, то уровень риска U - низкий. Если ранг риска R = 69%-30%, то уровень риска U - средний.Если ранг риска R = 29%-0%, то уровень риска U - высокий.3. Вычисление ранга и уровня риска каждого атрибута.Вычисление комбинированного риска элемента таксономии путем определения соотношения рисков атрибутов этого элемента и составление шкалы (или столбчатой диаграммы).Например, элемент “Требования” состоит из 7 атрибутов (приложение.1). Если по пяти атрибутам был получен высокий риск, а по 2 - средний, то соотношение рисков на шкале будет 2/7 для среднего и 5/7 для высокого риска. 4. Вычисление комбинированного риска по всем элементам.Аналогичным образом может быть установлен комбинированный риск проекта в целом путем определения соотношения рисков всех атрибутов таксономии.
Страницы: 1, 2, 3
|
