И. Соммервилл - Инженерия программного обеспечения (1133538), страница 26
Текст из файла (страница 26)
В принципе на этой стадии пе должна оцениваться вероятность и значимость рисков, но на практике маловероятные риски с незначительными последствиями обычно отбрасываются сразу. Определение рисков может выполняться в режиме командной работы с использоваинслт подхода "лтозговой ппурлт" либо основываться ца опыте ыспсджсра, Прн опрсттсле~птп рисков может помочь приведенный ниже список возможных категорий рисков. 1.
Техновоеичепеие виски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система. 2. Риски, евтптеттые е яереонлвотт. Связаны с членами команды разработчиков. Процесс управления рисками, как и другис процессы планирования, является итерационным, выполнлемым в течение всего срока реализации проекта. Сначала разрабатываются планы управления рисками, затем постолнно отслеживается ситуация вокруг реализации проекта. При поступлении новой информации о возможных рисках заново проводится анализ рисков и первостепенное внимание уделяется новым рискам.
По мере поступления новой информации также изменяются планы мероприятий но предотвращению и смягчению рисков. Результаты процесса управления рискалги документируются в виде планов управления рисказш. Они должны включать описание возможных проектных рисков, их анализ н перечень мероприятий, необходимых для > правления рисками.
96 я%асти 1, Инженерия программного обеспеченизп обзор 3. Организлккоккме Ряски. Проистекают из организационного окружения, в котором выполняется проект. 4. Ияструзмкяиыькме Улики. Связаны с используемыми САБЕсредствами и другими средствами поддержки процесса создания ПО. 5. Риски, аяиакнъи с сиояемнмми трсбоялкияки. Проявляются при изменении требований, предъявляемых к разрабатываемой системе.
б. Риски овгниепнкя Связаны с оцениваиием характеристик программной системы и ресурсов, необходимых для реализации проекта. Таблица 4.5. Категории рисков Категория Рисков Технологические риски Примеры рисков База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций. Программные компоненты, которые используются повторно, имеют дефекты, ограничивающие их функциональные воз. можности Риски, связанные с пер- соналом Невозможно подобрать работников с требуемым профессио.
нэльным уровнем. Ведущий разработчик заболел в самое критическое время. Невозможно организовать необходимое обучение персонала Организационные риски В организации, выполняющей разработку ПО, произошла ре. организация, в результате чего изменились приоритеты в управлении проектом.
Финансовые затруднения в организации привели к уменьше- нию бюджета проекта Инструментальные риски Программный код, генерируемый САБЕ-средствами, пс эффективен. САБЕ-средства невозможно интегрировать с другими средст- вами поддержки проекта Риски, связанные с сис. темными требованиями Излгенения требований приводят к значительным повторным работам по проектированию системы. Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований. проявившихся на поздних стадиях разработки проекта В табл.4.5 представлены некоторые примеры, относящиеся к каждой из описанных категорий рисков.
Результатом этапа определения рисков будет длинный список возможных рисков. которые мокнут повлиять на разрабатываемый программный продукт, проект или организацию.разработчика. 4. Управление проектами 97 Окончание табл. 4.5 Примеры рисков Категория рисков Недооценки времени выполнения проекта. Скорость выявления дефектов в системе ниже ранее заплани- рованной. Размер системы значительно превышает первоначально рас- считанный Риски оценивания 4А.2.
Анализ рисков При анализе для каждого определенного риска подсчитывается вероятность его про. явления и ущерб, который он может нанести. Не существует простых методов выполнения анализа рисков — в значительной мере он основан на мнении н опыте менеджера. Не претендуя на исключительную точность, можно привести гледующую шкалу вероятностей рисков и их последствий. 1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.
2. Возможный ущерб от рисковых ситуаций можно подразделить на катастрофический, серьезный, терпимый и незначительный. Таблица 4.6. Список рисков после проведения нх анализа Вероятность Степень ущерба Риск Финансовые затруднения в организации привели к уменьшению бюджета проекта Невозможно подобрать работников с требующимся профессиональным уровнем Низкая Катастрофическая Катастрофическая Высокая Средняя Серьезная Ведущий разработчик заболел в самое критическое время Программные компоненты, используемые повторно, имеют дефекты, ограничивающие их функциональ- ные возможности Средняя Серьезнал Серьезная Изменения требований приводят к значительным по- вторным работам по проектированию системы В организации, выполняющей разработку ПО, про.
изошла реорганизация, в результате чего изменились приоритеты в управлении проектом Средняя Серьезная Высокая Результаты аназиза рисков должны быть представлены в виде таблицы рисков, упорядоченных по степени возможного ущерба. В табл. 4.6 приведен упорядоченный список рисков, описанных в табл4.5; там же указаны вероятности этих рисков. Здесь вероятности рисков и степень ущерба от них указаны произвольно.
На практике для их определения необходима подробная информацил о проекте, технологии создания ПО, команде разра. ботчиков и о самой организации. 9В Часть Е Инженерня программного обеспечения: обзор Окончание щабл. 4.б Риск Вероятность Степеиьущерба База данных, которая используется в программной системе, нс обеспечивает обработку ожидаемого объ- ематранзакций Недооценки времени выполнения проекта САЯЕ-средства невозможно интегрировать с другими средствами поддержки проекта Первоначальная нечеткая формулировка пользова- тельских требований привела к значительным изме- нениям системных требований, проявившихся на поздних стадиях разработки проекта Невозможно организовать необходимое обучение персонала Скорость выявления дефектов в системс ниже ранее запланированной Размер системы значительно превьнпает первона- чально рассчитанный Программный код, генерируемый САЯЕ-средствами, неэффективен Серьезная Средняя Серьезная Терпимая Высокая Высокая Средняя Терпимая Средняя Терпимая Средняя Терпимая Терпимая Высокая Средняя Незначительная 4.4.3.
Планирование рисков Планирование заключается в определении стратегии управления каждым значимым риском, отобранным для мониторинщ после анализа рисков. Здесь также нс существует общспринлтых подходов для разработки таких стратегий — многое основывается па "чутье" и опыте мецсджсра проекта. В табл. 4.7 показаны возможные стратегии управления осповнымн рисками, приведенными а табл. 4.б. Конечно, как вероятность рисков, так и возможный ущерб от пих должны пересматриваться при поступлении дополнительной информации об этих рисках и по мере реализации мероприятий по управлению ими, Поэтому подобные таблицы рисков должны пс. рсделываться на каждой итерации процесса управления рисками.
После провеления анализа рисков определяются наиболес значимые риски, которые затем отслеживаются иа протяжении всего срока выполнения проекта. Определение этих значимых рисков зависит от их вероятностей и возможного ущерба. В общем случае всегда отслеживаются риски с катастрофическими последствиями, а также риски с серьезным ущербом, значение вероятности которых вьпае среднего. В статье [471 рекомендуется определить и отслеживать "1О верхних" рисков, но я ду.
маю, что это необоснованная рекомендация. Количество рисков, которые необходимо отслеживать, зависит от конкретного проекта. Это может быть пять рисков, а можст— пятнадцать. Но, конечно, количество рисков, по которым проводится мониторинг, долж. но быть обозримым. Большое количество отслеживаемых рисков потребует огромного количества собираемой информации.
Из списка рисков, представленных в табл. 4.б, для мониторинга следует отобрать все восемь рисков, которые мо~ут привести к катастрофическим и серьезным последствиям. 4. Управление проектами 99 Таблица 4.7. Стратегии управления рисками Риск Стратегия Финансовые проблемы ор. ганизации Подготовить краткий документ для руководства организа- ции, показывающий важность данного проекта для дости- жения финансовых целей организации Предупредить заказчика о потенциальных трудностях н возможной задержке проекта, рассмотреть вопрос о покуп- ке компонентов системы Проблемы неквалифициро- ванного персонала Реорганизовать работу команды разработчиков таким обра.
зом, чтобы обязанности и работа членов команды псрскры. вали друг друга, вследствие этого разработчики будут знать и понимать задачи, выполняемые другими сотрудниками Заменить потенциально дефектные системные компоненты покупныии компонентами, гарантируюпГими качество ра- боты Болезни персонала Дефектные системные ком- поненты Попытаться определить требования, наиболее вероятно подверженныс изменениям; в структуре системы не ото.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
