ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 12.01.2024
Просмотров: 150
Скачиваний: 7
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Практическая работа № 3
Тема. Управление рисками.
Цель. Изучить категории рисков и их признаки; научиться выполнять управление рисками: выделять наиболее возможные риски для проекта, выполнять анализ рисков и составлять стратегии для их решения.
Оборудование. ПК
Ход работы
-
Ознакомиться с теоретической частью. -
Выполнить практическое задание. -
Ответить на контрольные вопросы. -
Оформить отчет.
Теоретическая часть
Важной частью работы менеджера проекта является оценка рисков, которые могут повлиять на график работ или на качество создаваемого программного продукта, и разработка мероприятий по предотвращению рисков. Результаты анализа рисков должны быть отражены в плане проекта. Определение рисков и разработка мероприятий по уменьшению их влияния на ход выполнения проекта называется управлением рисками.
Упрощенно риск можно понимать как вероятность проявления каких-либо неблагоприятных обстоятельств, негативно влияющих на реализацию проекта. Можно выделить три типа рисков.
-
Риски для проекта, которые влияют на график работ или ресурсы, необходимые для выполнения проекта. -
Риски для разрабатываемого продукта, влияющие на качество или производительность разрабатываемого программного продукта. -
Бизнес-риски, относящиеся к организации-разработчику или поставщикам.
Конечно, эти типы рисков могут пересекаться. Например, если опытный программист покидает проект, это будет риском для проекта (поскольку задерживается срок сдачи готового продукта), риском для продукта (так как новый программист, заменивший ушедшего, может оказаться не слишком опытным и сделать ошибки в программе) и бизнес-риском (поскольку задержка данного проекта может негативно повлиять на будущие деловые контакты между заказчиком и организацией-разработчиком).
Многие типы рисков способны повлиять на любые программные проекты, эти риски приведены в таблице 4.1.
Таблица 4.1 – Возможные риски программных проектов
| Риск | Типы риска | Описание риска |
| Текучесть разработчиков | Риск для проекта | Опытные разработчики покидают проект до его завершения |
| Изменение в управлении организацией | Риск для проекта | Организация меняет свои приоритеты в управлении проектом |
| Неготовность аппаратных средств | Риск для проекта | Аппаратные средства, которые необходимы для проекта, не поступили вовремя или не готовы к эксплуатации |
| Изменение требований | Риск для проекта и для разрабатываемого продукта | Появление большого количества непредвиденных изменений в требованиях, предъявляемых к разрабатываемому ПО |
| Задержка в разработке спецификации | Риск для проекта и для разрабатываемого продукта | Спецификации основных интерфейсов подсистем не поступили к разработчикам в соответствии с графиком работ |
| Недооценка размера разрабатываемой системы | Риск для проекта и для разрабатываемого продукта | Размер системы значительно превысил первоначальную оценку |
| Недостаточная эффективность CASE-средств | Риск для разрабатываемого продукта | CASE-средства, предназначенные для поддержки проекта, оказались менее эффективными, чем ожидалось |
| Изменения в технологии разработки ПО | Бизнес-риск | Основные технологии построения программной системы заменяются новыми |
| Появление конкурирующего программного продукта | Бизнес-риск | На рынке программных продуктов до окончания проекта появилась конкурирующая программная система |
Схема процесса управления рисками показана на рисунке 4.1. Этот процесс состоит из четырех стадий.
-
Определение рисков. Определяются возможные риски для проекта, для разрабатываемого продукта и бизнес-риски. -
Анализ рисков. Оценивается вероятность и последовательность появления рисковых ситуаций. -
Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект. -
Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковых ситуаций.
Рисунок 4.1 – Схема процесса управления рисками
Процесс управления рисками, как и другие процессы планирования, является итерационным, выполняемым в течение всего срока реализации проекта. Сначала разрабатываются планы управления рисками, затем постоянно отслеживается ситуация вокруг реализации проекта. При поступлении новой информации о возможных рисках заново проводится анализ рисков и первостепенное внимание уделяется новым рискам. По мере поступления новой информации также изменяются планы мероприятий по предотвращению и смягчению рисков.
Результаты процесса управления рисками документируются в виде планов управления рисками. Они должны включать описание возможных проектных рисков, их анализ и перечень мероприятий, необходимых для управления рисками.
Определение рисков
Определение рисков – первая стадия процесса управления рисками. На этой стадии описываются риски, которые могут проявиться при реализации проекта. В принципе на этой стадии не должна оцениваться вероятность и значимость рисков, но на практике маловероятные риски с незначительными последствиями обычно отбрасываются сразу.
Определение рисков может выполняться в режиме командной работы с использованием подхода "мозговой штурм" либо основываться на опыте менеджера. При определении рисков может помочь приведенный ниже список возможных категорий рисков.
1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система.
2. Риски, связанные с персоналом
. Связаны с членами команды разработчиков.
3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект.
4. Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО.
5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе.
6. Риски оценивания. Связаны с оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта.
В таблице 4.2 представлены некоторые примеры, относящиеся к каждой из описанных категорий рисков. Результатом этапа определения рисков будет длинный список возможных рисков, которые могут повлиять на разрабатываемый программный продукт, проект или организацию-разработчика.
Таблица 4.2 – Категории рисков
| Категория рисков | Примеры рисков |
| Технологические риски | База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций. Программные компоненты, которые используются повторно, имеют дефекты, ограничивающие их функциональные возможности |
| Риски, связанные с персоналом | Невозможно подобрать работников с требуемым профессиональным уровнем. Ведущий разработчик заболел в самое критическое время. Невозможно организовать необходимое обучение персонала |
| Организационные риски | В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проектом. Финансовые затруднения в организации привели к уменьшению бюджета проекта |
| Инструментальные риски | Программный код, генерируемый CASE-средствами, не эффективен. CASE-средства невозможно интегрировать с другими средствами поддержки проекта |
| Риски, связанные с системными требованиями | Изменения требований приводят к значительным повторным темными требованиями работам по проектированию системы. Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта |
| Риски оценивания | Недооценки времени выполнения проекта. Скорость выявления дефектов в системе ниже ранее запланированной. Размер системы значительно превышает первоначально рассчитанный |
Анализ рисков
При анализе для каждого определенного риска подсчитывается вероятность его проявления и ущерб, который он может нанести. Не существует простых методов выполнения анализа рисков – в значительной мере он основан на мнении и опыте менеджера. Можно привести следующую шкалу вероятностей рисков и их последствий.
1. Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.
2. Возможный ущерб от рисковых ситуаций можно подразделить на катастрофический, серьезный, терпимый и незначительный.
Результаты анализа рисков должны быть представлены в виде таблицы рисков, упорядоченных по степени возможного ущерба. В таблице 4.2 приведен упорядоченный список рисков, описанных в таблице 4.1; там же указаны вероятности этих рисков. Здесь вероятности рисков и степень ущерба от них указаны произвольно. На практике для их определения необходима подробная информация о проекте, технологии создания ПО, команде разработчиков и о самой организации.
Конечно, как вероятность рисков, так и возможный ущерб от них должны пересматриваться при поступлении дополнительной информации об этих рисках и по мере реализации мероприятий по управлению ими. Поэтому подобные таблицы рисков должны переделываться на каждой итерации процесса управления рисками.
После проведения анализа рисков определяются наиболее значимые риски, которые затем отслеживаются на протяжении всего срока выполнения проекта. Определение этих значимых рисков зависит от их вероятностей и возможного ущерба. В общем случае всегда отслеживаются риски с катастрофическими последствиями, а также риски с серьезным ущербом, значение вероятности которых выше среднего.
Таблица 4.3 – Список рисков после проведения их анализа
| Риск | Вероятность* | Степень ущерба |
| Финансовые затруднения в организации привели к уменьшению бюджета проекта | Низкая | Катастрофическая |
| Невозможно подобрать работников с требующимся профессиональным уровнем | Высокая | Катастрофическая |
| Ведущий разработчик заболел в самое критическое время | Средняя | Серьезная |
| Программные компоненты, используемые повторно, имеют дефекты, ограничивающие их функциональные возможности | Средняя | Серьезная |
| Изменения требований приводят к значительным повторным работам по проектированию системы | Средняя | Серьезная |
| В организации, выполняющей разработку ПО, произошла реорганизация, в результате чего изменились приоритеты в управлении проектом | Высокая | Серьезная |
| База данных, которая используется в программной системе, не обеспечивает обработку ожидаемого объема транзакций | Средняя | Серьезная |
| Недооценки времени выполнения проекта | Высокая | Серьезная |
| CASE-средства невозможно интегрировать с другими средствами поддержки проекта | Высокая | Терпимая |
| Первоначальная нечеткая формулировка пользовательских требований привела к значительным изменениям системных требований, проявившихся на поздних стадиях разработки проекта | Средняя | Терпимая |
| Невозможно организовать необходимое обучение персонала | Средняя | Терпимая |
| Скорость выявления дефектов в системе ниже ранее спланированной | Средняя | Терпимая |
| Размер системы значительно превышает первоначально рассчитанный | Высокая | Терпимая |
| Программный код, генерируемый CASE-средствами, неэффективен | Средняя | Незначительная |
Из списка рисков, представленных в таблице 4.3, для мониторинга следует отобрать те риски, которые могут привести к катастрофическим и серьезным последствиям для вашего проекта.
Планирование рисков
Планирование заключается в определении стратегии управления каждым значимым риском, отобранным для мониторинга после анализа рисков. В таблице 4.4 показаны возможные стратегии управления основными рисками, приведенными в таблице 4.3.
Таблица 4.4 – Стратегии управления рисками
| Риск | Стратегия |
| Финансовые проблемы организации | Подготовить краткий документ для руководства организации, показывающий важность данного проекта для достижения финансовых целей организации |
| Проблемы неквалифицированного персонала | Предупредить заказчика о потенциальных трудностях и возможной задержке проекта, рассмотреть вопрос о покупке компонентов системы |
| Болезни персонала | Реорганизовать работу команды разработчиков таким образом, чтобы обязанности и работа членов команды перекрывали друг друга, вследствие этого разработчики будут знать и понимать задачи, выполняемые другими сотрудниками |
| Дефектные системные компоненты | Заменить потенциально дефектные системные компоненты покупными компонентами, гарантирующими качество работы |
| Изменения требований | Попытаться определить требования, наиболее вероятно подверженные изменениям; в структуре системы не отображать детальную информацию |
| Реорганизация компании-разработчика | Подготовить краткий документ для руководства компании, показывающий важность данного проекта для достижения финансовых целей компании |
| Недостаточная производительность базы данных | Рассмотреть возможность покупки более производительной базы данных |
| Недооценки времени выполнения проекта | Рассмотреть вопрос о покупке системных компонентов, исследовать возможность использования генератора программного кода |