МЕТОДЫ УПРАВЛЕНИЯ РИСКАМИ ПРОЕКТА

1.1. СОДЕРЖАНИЕ ПРОБЛЕМЫ УПРАВЛЕНИЯ РИСКАМИ

Проблема управления рисками проекта является одной из основных и особо важных в общем перечне проблем и задач управления проектами по созданию конкурентно способной и качественной продукции и в том числе программной продукции. Убедительным свидетельством важности и актуальности этой проблемы являются многочисленные и многолетние зарубежные и отечественные научно-практические исследования, проведенные и опубликованные такими общеизвестными и авторитетными организациями как: Институт Управления Проектами (США), Институт Программной Инженерии (США), Университет Мэриленда (США), SPMN (Сеть управления программами создания ПО (США), Российский Институт Управления Проектами, и др [10].

Основными понятиями в проблеме управления рисками проекта являются понятия «риска» и «неопределенности». Риск является объективным явлением, природа которого обусловлена недетерминированностью (неоднозначностью) событий будущего. Он связан с ущербом, потерей, упущенной возможностью. Когда наступает ущерб, потеря, происходит практическое проявление риска. До этого риск остается гипотетической опасностью.

Неопределенность в проекте можно охарактеризовать как множество состояний внутренней и внешней среды проекта. При реализации проекта всегда необходимо осуществлять поиск наилучшего (в каком-нибудь смысле) решения на заранее заданном множестве допустимых решений. Основная проблема состоит в том, что последствия, связанные с принятием того или иного решения, зависят от неизвестной ситуации (неопределенности). Степень неприемлемости этих последствий измеряется в условных единицах - потерях, которые может понести проект.

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

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

Отсюда очевидно, что если удается каким либо способом (на основе опыта) до начала проекта и в процессе проекта определять (идентифицировать) необходимый перечень рисковых событий (рисков), отслеживать эти риски по ходу проекта и адекватно реагировать на них, то в принципе можно управлять последствиями рисковых событий и тем самым управлять успешным завершением проекта. Указанный принцип управления рисками проекта используется практически во всех, созданных и используемых на сегодняшний день, методологиях, технологиях, методах и процессах управления рисками проектов программных изделий.

Управление риском проекта - это искусство и формальные методы прогнозирования, анализа, оценки, предупреждения возникновения рисковых событий; принятия мер по снижению степени риска на протяжении жизни проекта и распределения возможного ущерба от риска между участниками проекта являются взаимосвязанными средства достижения целей проекта .

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

Согласно классическим подходам процесс управления рисками программного проекта разделяется на этапы, на которых менеджеры проекта, эксперты, специалисты и другие участники проекта принимают многочисленные и многократные решения по выбору состава контролируемых рисков, по определению рисковых ситуаций, по выбору вариантов реагирования на риски (смягчения рисков) с учетом критериев и целей проекта.

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

Формальное представление принципов принятия решений (ПР) менеджерами проекта можно сформулировать следующим образом: имеется (или определяется) множество вариантов решения (альтернатив), реализация каждой альтернативы приводит к наступлению некоторых последствий (исходов), анализ и оценивание исходов по набору показателей эффективности (критериев) процесса управления рисками однозначно характеризует альтернативы. Требуется, изучив предпочтения менеджеров (экспертов), построить модель выбора альтернативы, лучшей в некотором конкретном смысле.

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

<А, Е, S, T>, (1.1)

где исходами задачи полагаются: А – множество альтернатив; Е – среда задачи ПР; S – система предпочтений лица принимающего решения (ЛПР). Требуется выполнить некоторое действие Т над множеством альтернатив А: найти наиболее предпочтительную альтернативу, выделить множество недоминируемых альтернатив, линейно упорядочить множество допустимых альтернатив и т.п.

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

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

Согласно общей классификации применительно к постановке (1.1) можно выделить задачи принятия решений:

· в условиях определенности, когда каждой альтернативе соответствует строго определенный исход;

· в условиях риска, где исход является дискретной или непрерывной случайной величиной с известным законом распределения;

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

Здесь следует особо подчеркнуть и заметить, что проекты, связанные с информационными технологиями, содержат в своем составе задачи принятия решения в условиях неопределенности.

Решение (1.1) будем определять как подмножество D множества альтернатив, образованное на основе системы предпочтений ЛПР в соответствии с типом задачи по этапам поддержки процесса управления рисками качества программных проектов. При этом важным обстоятельством проблемы управления рисками качества является наличие современной модели характеристик качества ПИ, которая необходима с одной стороны для понимания масштаба и размерности задач принятия решений, а с другой стороны определяет выбор и разработку требуемых подходов и методов поддержки принятия проектных решений.

1.2. МОДЕЛЬ КАЧЕСТВА ПРОГРАММНОГО ПРОЕКТА С ПОЗИЦИЙ УПРАВЛЕНИЯ РИСКАМИ КАЧЕСТВА

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

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

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

Таким образом, все события проекта, которые могут рассматриваться (по разным причинам) признаками угроз (ущерба) качеству проекта программных изделий, относятся к рисковым событиям, которые должны подпадать под влияние процесса управления рисками качества проекта программных изделий. С другой стороны, управление рисковыми событиями (смягчение рисков) в рамках процесса управления рисками, очевидно, должно способствовать более успешному выполнению и завершению проекта, т.е. более полному удовлетворению заявленным требованиям и целям проекта и тем самым повышению качества программных изделий.

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

Современная формальная модель качества программного изделия может быть представлена в виде иерархического дерева характеристик и субхарактеристик в соответствии с требованиями государственных и международных стандартов в области качества (рисунок 1.1):

1) ISO 9126:1991. (ГОСТ Р ИСО/МЭК 9126-93) Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению.

2) ISO 9126 1-4:2000. Информационная технология. Качество программных средств:

• часть 1: Модель качества;

• часть 2: Внешние метрики качества;

• часть 3: Внутренние метрики качества;

• часть 4: Метрики качества в использовании.

3) ISO 14598 1-6: 1998-2000. Оценивание программного продукта:

• часть 1:1999. Общий обзор;

• часть 2:2000. Планирование и управление;

• часть 3:2000. Процесс для разработчиков;

• часть 4:1999. Процесс для приобретателей;

• часть 5:1998. Процесс для оценщиков (испытателей);

• часть 6:2001. Документирование оценки модулей (проект).

Такая модель характеристик качества разделяет общее качество программных средств на шесть групп базовых показателей, далее структурированных на субхарактеристики. Самый высокий уровень такой структуры состоит из характеристик качества (функциональные возможности, надежность, эффективность, практичность, сопровождаемость, мобильность), а нижний уровень состоит из их атрибутов.

Эта иерархия модели не является строгой, т.к. многие атрибуты модели могут быть связаны с более чем одной субхарактеристикой, а внешние свойства влияют на наблюдаемое внутреннее качество. При этом для программных проектов модель качества программного изделия может иметь свою отличительную структуру для каждой стадии ЖЦ проекта.

Таким образом, из модели характеристик и субхарактеристик качества ПИ следует понимание области определения рисков качества программного изделия. Эта область рисков качества для каждого программного проекта и каждой его стадии определяется индивидуально и задается моделью (деревом) его характеристик и субхарактеристик качества. При этом сложность построения такой модели заключается в том, что программные продукты представляют собой интеллектуальные нематериальные изделия, сам уникальный характер которых затрудняет их специфицирование и оценку.

1.3. МЕТОДИЧЕСКАЯ БАЗА ПРОЦЕССА УПРАВЛЕНИЯ РИСКАМИ ПРОЕКТА

Современное состояние научно-методической и нормативной базы управления рисками проекта показывает, что на сегодняшней день основной методической базой процесса управления рисками программного проекта являются следующие:

· научно-методические документы международного уровня, стандарты и документы ИСО, ИСО/МЭК;

· государственные стандарты России в области (создания) управления качеством программных средств;

· ведомственные и корпоративные стандарты и документы.

1.3.1. НОРМАТИВНАЯ БАЗА МЕЖДУНАРОДНОГО УРОВНЯ

Основными научно-методическими документами международного уровня, которые регламентируют или затрагивают проблему управления рисками, а также дают рекомендации по организации процессно-ориентированного подхода к построению системы управления рисками проекта программных средств могут рассматриваться [1,2]:

· ISO 9001:1994г. (ГОСТ Р ИСО 9001-96) Системы качества. Модель обеспечения качества при проектировании, разработке, изготовлении, постановке на производство и обслуживании.

· ISO/TR 10006:1997г. Менеджмент качества. Руководство качеством при управлении проекта.

· ISO/IEC 12207:1995г. Информационная технология. Процессы жизненного цикла программного обеспечения.

· ISO/TMB WG RMT N34 rev: 2001 г. Терминология управления рисками. Руководство для использования в стандартах.

· ISO/IEC TR 15504 - СММ (ИСО\МЭК ТО 15504). Оценка и аттеста­ция зрелости процессов создания и сопровождения программных средств и информационных систем.

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

ISO 9001:1994 (ГОСТ Р ИСО 9001-96) «Модель обеспечения качества при проектировании, разработке, монтаже и обслуживании» устанавливает требования к системе качества, необходимые для оценки возможности поставщика проектировать и поставлять продукцию, соответствующую установленным требованиям. При этом установленные требования направлены, в первую очередь, на удовлетворение потребителя посредством предупреждения несоответствия продукции на всех стадиях от проектирования до обслуживания. Стандарт ISO 9000-3-91 «Общее руководство качеством и стандарты по обеспечению качества. Часть 3. Руководящие указания по применению ISO 9001 при разработке, постановке и обслуживанию программного обеспечения», который дополняет положения ISO 9001 применительно к программной продукции. Положения этих документов учтены при разработке концептуальных моделей процесса управления рисками качества наукоемких программных проектов.

ISO/TR 10006:1997 "Менеджмент качества. Руководство качеством при управлении проектами" непосредственным образом затрагивает проблемы управления рисками, где на самом высоком уровне приведена структура процесса управления рисками без привязки к типу проектов по созданию продукции различного назначения.

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

Структура процесса управления рисками включает подпроцессы: выявление рисков в проекте; оценка рисков - оценивание вероятности появления рисковых событий и их воздействия на проект; развитие реакции на риски - разработка планов реагирования на риски; контроль за рисками - реализация и обновление рисковых планов.

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

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

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

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

ISO/TMB WG RMT N34 "Терминология процесса управления рисками проекта" содержит необходимую терминологию для методологий и технологий управления рисками. Документ создан международной организацией по стандартизации в связи с чрезвычайной важностью проблемы управления рисками и упорядочивает терминологию в этой области знаний для последующих научных и практических разработок.

ISO/IEC TR 15504 - СММ (ИСО/МЭК ТО 15504). «Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем» - содержит в группе организационных процессов жизненного цикла краткое описание процесса административного управления рисками. Назначением процесса является постоянное выявление и устранение рисков в проекте на протяжении всего жизненного цикла проекта.

1.3.2. НОРМАТИВНАЯ БАЗА ГОСУДАРСТВЕННОГО УРОВНЯ

Российские стандарты. Общие положения по оценке качества программного изделия вычислительной техники, номенклатура и применяемость показателей качества программного изделия представлены в ГОСТ 28195-89 г. «Оценка качества программных средств». Этот документ содержит показатели качества программного изделия, распределенные по фазам ЖЦ программного изделия с указанием метрик, которые могут быть учтены при разработке процедур идентификации и оценки рисков качества программного изделия. Однако некоторые положения этого стандарта не отражают требований к качеству современных программных изделий и альтернативой данному стандарту является группа современных международных стандартов серии ISO (ISO 9126 -1-4:1991-2000; ISO 14598 1-6: 1998-2000).

Зарубежные стандарты. MIL-STD-498:1994 "Разработка и документирование программного обеспечения". Документ утвержден для применения всеми ведомствами и органами министерства обороны США, в котором указано, что разработчик должен осуществлять управление рисками на протяжении всего процесса разработки программного изделия. При этом разработчик должен идентифицировать, провести анализ и установить приоритеты участников проекта разработки программного изделия, связанных с потенциальными техническими рисками, а также рисками по затратам или графикам, и разработать стратегию управления этими рисками; записать риски и стратегию в плане разработки программного изделия; реализовать стратегию в соответствии с планом. Все это свидетельствует о важности проблемы управления рисками в проектах военных программных изделий.

1.3.3. НОРМАТИВНАЯ БАЗА КОРПОРАТИВНОГО УРОВНЯ

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

· стандарт РМВОК (Project management body of knowledge) Project Management Institute США;

· метод PJM (Project Management Method) корпорации Oracle;

· метод SEI(Software Engineering Institute) Института программной инженерии США;

· метод Riskit(The Riskit Method for Software Risk Management) университета Мэриленда (США);

· «лучшие практические навыки» SPMN(Software Program Managers Network) Сеть управления программами создания программного обеспечения США;

· метод MSF (Microsoft Solutions Framework) -корпорации Microsoft.

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

PMBOK (A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE) "Свод знаний по управлению проектами"

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

PJM (PROJECT MANAGEMENT METHOD) Корпорации Oracle "Стандартный подход к руководству проектом"

Рассматриваемый корпоративный документ, представляет стандартный подход к руководству программным проектом, который является составной частью глобальной методологии Oracle Method, предназначенной для согласованного планирования, оценки, управления и завершения проектов всех типов, связанных с информационными технологиями. Эта согласованность необходима в современной среде, где при выполнении проектов реализуется множество методов, инструментальных средств и подходов для выполнения технических требований по проекту, и соответственно возникает множество проблем, связанных с рисками проекта.

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

Метод SEI (Software Engineering Institute) Института программной инженерии (США)

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

Согласно этой методологии SEIструктуру процесса управления рисками программного проекта поддерживают три группы методов: оценка рисков программного проекта (метод SRE); непрерывное управление рисками (метод CRM); управление коллективным (корпоративным) риском (метод TRM).

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

Парадигма управления риском в SEI по существу определяет структуру для управления рисками программного проекта и согласно методологии SEI включает последовательность действий (этапов), образующих замкнутый круг (идентификация рисков - анализ рисков - планирование управления рисками - слежение за рисками - управление рисками - идентификация рисков). Замкнутость последовательности этапов подчеркивает, что управление рисками - непрерывный процесс, а последовательность этапов показывает логический поток информации между действиями.

Таксономия рисков - определяет и использует методы идентификации рисков, как первый шаг системного и непрерывного метода управления рисками SEI для увеличения вероятности успешного завершения проекта. Таксономия (классификация) предоставляет инженерную систему для исследования диапазона разрабатываемых программ и, таким образом, определяет общую структуру и организацию идентификации потенциальных рисков наукоемких программных проектов. Метод, используемый в SEI, состоит из классификационного вопросника (TBQ) и процесса для его применения, которые разработаны на основе обширных экспертных знаний и результатах различных практических исследований. Таксономия организует формальную разработку (определение) рисков на 3-х уровнях: класс риска; элемент риска и атрибут риска. TBQ состоит из вопросов для каждого таксономического атрибута, на которые необходимо участникам проекта и экспертам дать ответы, на основании которых делаются выводы по рискам. Практически этот процесс идентификации рисков состоит из серии интервью с группами выбранного персонала проекта и экспертами.

Диагностика рисков представляет собой симпозиум экспертов и участников проекта, на котором методы CRM и TRM приспосабливаются и объединяются с каналами связи клиента, инфраструктурой, существующими методами руководства проектом, управления рисками и техническим прикладным управлением. Диагностика рисков - краеугольный камень процесса диалогового взаимодействия разработчика программного изделия и клиента по вопросам анализа рисков, оценке альтернативных действий и процедур реагирования на риски, что в общем случае может занимать для крупных наукоемких программных проектов от нескольких дней до нескольких месяцев.

Метод RISKIT

Метод Riskit (The Riskit Method for Software Risk Management) разработан в университете Мэриленда (США) и предназначен для управления рисками разработки программного изделия. Основные шаги формального подхода Riskit в управлении рисками программного проекта соответствуют положениям стандартов, руководств и документов международного, корпоративного и ведомственного уровня. При этом следует отметить, что указанный метод в настоящее время не поддерживает процесс управления рисками качества проектов программных изделий.

К достоинствам метода можно отнести:

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

- использование оригинального графического способа (языка) представления сценария каждого риска (графом сценария риска) позволяет экспертам более объективно оценить степень важности каждого идентифицированного риска. Применение здесь инструментальных средств «рисования» графа сценария для каждого анализируемого риска повышает производительность работ и снижает трудоемкость метода;

- применение шаблонов документации, инструментальных средств обработки текстов и программного обеспечения электронной таблицы в совокупности упрощает документирование и обработку информации по рискам.

К ограничениям и узким местам метода следует указать:

- сложность и не эффективность применения Riskit на этапе идентификации и мониторинга, а также на этапе анализа и планирования технических рисков (рисков качества программного изделия) вследствие большой размерности задач принятия решений экспертами не автоматизированными способами, а также Riskit принципиально не способен учитывать особенности процесса управления рисками качества наукоемких программных проектов, которые принципиально основываются на иерархической модели характеристик и субхарактеристик качества программного изделия;

- отсутствие инструментальных средств поддержки принятия решений, необходимых для многократного использования по этапам процесса управления рисками и стадиям ЖЦ наукоемких программных проектов в целях выбора альтернатив адекватных предпочтениям экспертов (специалистов), выражаемых качественным или количественным способом.

SPMN "Лучшие практические навыки"

Руководство «Лучшие практические навыки» было создано в 1998 году «Инициативной труппой» под руководством и при финансировании подразделения SPMN (Software Program Managers Network - Сеть управления программами создания ПИ) и при поддержке исполнительных органов управления программами министерства обороны США, военных центров, промышленных ассоциаций, государственных и отраслевых организаций, заинтересованных в совершенствовании технологии разработки ПИ. Создание документа стало возможным только благодаря целенаправленной работе 190 заинтересованных, ответственных, опытных руководителей проектов разработки ПИ, практиков, ведущих специалистов и экспертов промышленных предприятий и государственных органов, которые составили семь «Групп периодических обновлений» (Issue Panel), «Группу управления» (Programm Managers Panel) и «Группу оперативных советов» (Airlie Software Council).

Руководство «Лучшие практические навыки» сфокусировано на процессах эффективного управления, методах выявления дефектов и рисков по мере их появления, исключения чрезмерных и ненужных затрат, повышении производительности труда и других полезных эффектах.

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

Метод MSF (Microsoft Solutions Framework)

Метод MSF корпорации Microsoft включает набор (дисциплин) принципов и правил деятельности ориентированный на проекты разработки программного изделия и развития информационной инфраструктуры. В число принципов (моделей) входит модель управления рисками, описывающая порядок выявления наиболее существенных рисков и упреждающего реагирования на них. Анализ MSF показал, что уровень описания модели управления рисками в MSF примерно соответствует уровню, представленному и ранее рассмотренному в РМВОК. Положения этих документов учтены в учебном пособии при разработке концептуальных моделей процесса управления рисками качества наукоемких программных проектов.

1.3.4. ХАРАКТЕРИСТИКИ МЕТОДОВ УПРАВЛЕНИЯ РИСКАМИ

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

Таблица 1.1 – Методы, поддерживающих процессы управления рисками наукоемких программных проектов

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

1.4. ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ ПРОЦЕССА УПРАВЛЕНИЯ РИСКАМИ

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

Концептуальная функциональная IDEF0модель процесса управления рисками программного проекта, разработанная с использованием инструментального средства BpWin 4.0, представлена на рисунках 1.2 - 1.8. Достоинствами этой модели являются: высокая степень наглядности, информативность, возможность коллективного обсуждения и адаптации под задачи конкретного программного проекта. Модель отражает на функциональном и структурном уровне общие вопросы и детали процессов и методов управления рисками проектов, которые прописаны и представлены в существующей нормативной базе. Основными процессами, отраженными в модели процесса управления рисками качества программного проекта, являются: идентификация рисков, анализ рисков, планирование рисков, мониторинг рисков.

Идентификация рисков подразумевает здесь определение и документирование рисков, способных повлиять на проект, т.е. повлиять на характеристики качества программного изделия такие как: надежность, сопровождаемость, удобство применения, и др.

Входной информацией данного подпроцесса является:

· описание среды проекта. Возникающие риски существенно зависят от среды проекта, под которой понимается совокупность внешних и внутренних факторов, влияющих на достижение результатов проекта;

· историческая информация. Информация о том, что в действительности происходило в аналогичных проектах, может быть особенно полезной для идентификации потенциальных рисков;

· показатели проекта. Характеристики проекта, вытекающие из его целей и задач, определяемые на стадии разработки концепции, необходимые для обоснования целесообразности и осуществимости проекта, анализа основных аспектов, оценки степени достижения целей и сравнении фактических результатов проекта с планируемыми;

Рис. 1.2 – Концептуальная модель А-0 процесса «Управление

рисками качества наукоемких программных проектов»

Рис. 1.3 – Концептуальная модель А0 процесса «Управление

рисками качества наукоемких программных проектов»

· база данных по рискам. Содержит перечень рисков качества проектов программных изделий, которые классифицированы в базе данных на риски процессов проектирования программных изделий, на риски процессов управления программными проектами и на риски характеристик качества программных изделий.

На выходе подпроцесса идентификации рисков получаются:

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

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

Методами и средствами данного подпроцесса могут являться:

· Методы идентификации рисков качества.

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

Входная информация данного процесса представлена на рисунке 1.3, и на выходе процесса имеем совокупность (перечень) контролируемых рисков качества наукоемких программных проектов. Основным методом поддержки процесса анализа рисков качества является метод мозгового штурма.

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

а) избежание рискового события;

б) смягчение возможных последствий;

в) принятие ущерба от рискового события.

В данном подпроцессе (рисунок 1.3) на основе «Совокупности контролируемых рисков качества» и «Базы данных по рискам» экспертами осуществляется планирование рисков и формирование списков «Альтернативы реагирования» и «Признаки возникновения ПРС».

Мониторинг рисков подразумевает непрерывную по стадиям ЖЦ проекта идентификацию ситуаций возникновения рисков и определение оптимальной альтернативы реагирования на идентифицированный риск.

Входная информация данного процесса представлена на рисунке 1.3, где:

· События проекта. Это результат выполнения всех работ, входящих в данное событие, позволяющий начинать все выходящие из него работы.

Выходной информацией данного процесса является «План смягчения идентифицированных рисков».

Детальные функциональные модели процессов: «Идентификация рисков», «Анализ рисков», «Планирование рисков» и «Мониторинг рисков» представлены после операции декомпозиции на рисунках 1.4-1.8, а модель потоков данных отображена на рисунке 1.9.

1.5. КОНЦЕПТУАЛЬНАЯ ИНФОРМАЦИОННАЯ МОДЕЛЬ

Концептуальная информационная модель процесса управления рисками качества программных проектов, разработанная с использованием CASE-средства ERWin, представлена на рисунке 1.10. Модель отражает все сущности, атрибуты (характеристики) сущностей и связи между ними, что позволяет на основе этой модели осуществить синтез далее логической и физической модели базы данных рисков качества программных проектов.

Функциональная, информационная модели и модель потоков данных процесса управления рисками качества программных проектов (рисунки 1.2-1.10) содержат системные представления о функциях (задачах) процессов управления рисками, взаимосвязях решаемых задач, информационных потоках, структуре рисковой информации, а также о видах неопределенности при принятии решений в рамках процесса управления рисками.

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

В зависимости от количества отсутствующей информации можно выделить здесь следующие виды неопределенности в задачах принятия решений по рискам: неизвестность, недостоверность (неполнота, недостаточность, недоопределенность, неадекватность) и неоднозначность.

В процессе сбора информации (методами анкетирования, интервьюирования, построением графов сценариев рисков и др.) на определенном этапе может оказаться, что собрана еще не вся возможная (неполнота) или не вся необходимая (недостаточность) информация. Или для некоторых элементов рисковой информации определены не их точные описания, а лишь множества, которым эти описания принадлежат (недоопределенность), или ряд элементов задачи временно описан лишь по аналогии с уже решавшимися задачами (например, по результатам аналогичных проектов), имеется лишь «замещающее» описание (неадекватность).

Рис. 1.4 – Функциональная модель процесса

«Идентификация рисков»

Рис. 1.5 – Функциональная модель процесса «Анализ рисков»

Рис. 1.6 – Функциональная модель подпроцесса «Интеграция

оценок на обобщенный критерий качества проекта»

Рис. 1.7 – Функциональная модель процесса «Планирование

рисков»

Рис. 1.8 – Функциональная модель процесса «Мониторинг рисков»

Рис. 1.9 – Модель потоков данных процесса управления рисками

качества программного проекта

		Рис. 1.10 – Информационная модель процесса управления рисками качества программного проекта

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

Источниками (причинами) возможной неоднозначности описания предметной области процесса управления рисками качества программных проектов являются внешняя среда (физическая неопределенность) и используемый экспертами (специалистами) профессиональный язык (лингвистическая неопределенность), который вследствие субъективного фактора может восприниматься (интерпретироваться) специалистами неоднозначно.

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

1.6. ЗАДАЧИ ПРИНЯТИЯ РЕШЕНИЙ ПО РИСКАМ

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

<A, X, K, f, P_S; D, T >, (1.2)

где исходными являются: А- множество альтернатив (например, множество потенциальных рисковых событий на этапе анализа); Х - множество исходов альтернатив (последствия ПРС); К– векторный критерий оценки исходов (модель качества программного изделия); f – отображение множества Х в множество векторных оценок (оценка степени влияния последствий ПРС на характеристики качества программного изделия); P_S – структура предпочтений лица принимающего решения (определяет структуру процедуры отображения Хв К).

Необходимо построить некоторое решающее правило или алгоритм D, позволяющий производить требуемое действие Тнад множеством альтернатив А. Среда и система предпочтений в (1.2) представляются элементами X, K, f, Ps, D. При этом каждой альтернативе А соответствует единственный исход X, который характеризуется векторной оценкой К.

Система предпочтений экспертов в процессе управления рисками качества выражается совокупностью определенных множеств (критериев, альтернатив, исходов) с отношениями предпочтения, выражаемыми вербально или количественно, и может рассматриваться некоторой эмпирической системой с отношениями. Поэтому структурированное представление системы предпочтений специалистов по рискам в виде системы с отношениями является структурой предпочтений ЛПР. В свою очередь структура предпочтений определяет процедуру сравнения оценокК, а решающее правило или алгоритм - принцип выбора элементов из множества А на основе результатов сравнения в соответствии с требуемым действием Т.

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

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

1. Ограничения на ресурсы процесса управления рисками качества программных проектов (временные, стоимостные) не позволяют получить в принципе существующую четкую информацию и вынуждают системных аналитиков воспользоваться знаниями и опытом экспертов, которые выражаются в нечеткой словесной форме, и задача принятия решений в процессе управления рисками качества оказывается погруженной в нечеткую среду.

2. Имеющаяся числовая информация (например, на этапе анализа рисков в виде системы предпочтений) не позволяет найти решение формальными методами при существующих методах и ограничениях на ресурсы, но ЛПР (эксперт) может найти его на основе своего опыта и задача принятия решений в этом случае является нечеткой по постановке.

3. На этапах анализа и мониторинга рисков имеется ряд альтернативных вариантов идентификации рисков, ранжирования рисков, реагирования на риски, но неизвестно точно, каким именно свойствами и качеством будет обладать программный продукт в конце проекта. При этом в условиях ограниченных ресурсов возникает задача отсева части вариантов на основе векторного показателя качества с нечеткими оценками значений его компонентов.

Дата добавления: 2014-08-09; просмотров: 1930; Нарушение авторских прав

Мы поможем в написании ваших работ!