
- •Введение
- •1 Основные понятия программной инженерии как промышленной технологии создания программных продуктов
- •1.1 Определение и особенности программного продукта
- •2.2 Объектно-ориентированная методология построения моделей бизнес-процессов
- •3 Модели разработки программного продукта
- •3.1 Каскадная модель
- •3.2 Модель прототипирования
- •3.3 Модель быстрой разработки приложений
- •4 Жизненный цикл разработки программного продукта
- •4.1 Стандарты на процессы жизненного цикла разработки программного продукта
- •4.2 Разработка и анализ требований
- •4.2.1 Понятие и классификация требований
- •4.2.2 Процессы работы с требованиями
- •4.3 Проектирование программных продуктов
- •4.3.1 Содержание этапа проектирования
- •4.3.2 Типовые архитектуры программных систем
- •4.3.3 Процессы проектирования программных продуктов
- •4.3.4 Моделирование процессов разработки архитектуры программной системы управления и контроля работы скорой помощи
- •4.4 Конструирование программного продукта
- •4.4.1 Процессы и инструментальные средства конструирования
- •Раздел 1. «Выпустить»
- •Раздел 2. «Лучший продукт»
- •Раздел 3. «Выпустить точно в срок»
- •4.5 Тестирование программного продукта
- •5 Жизненный цикл вывода на рынок программного продукта
- •5.1 Ввод в эксплуатацию и сопровождение программного продукта
- •5.2 Продвижение тиражного программного продукта на рынок
- •6 Управление программными проектами
- •6.1 Основные понятия и определения
- •6.2 Этапы жизненного цикла программного проекта
- •6.3 Управление содержанием и сроками реализации программного проекта
- •6.4 Управление качеством программного проекта
- •6.5 Управление рисками программного проекта
- •6.5.1 Риски и рискообразующие факторы программного проекта
- •6.5.2 Качественный и количественный анализ рискообразующих факторов
- •6.5.3 Стратегии управления рисками
- •Заключение
- •Литература
- •Глоссарий

114
Таблица 6.6 – Оценка рейтинга рискообразующих факторов
Близость |
|
Степень критичности |
|
|||
|
Умерен- |
Сред- |
|
Катастрофи- |
||
наступления |
Невысокая |
Высокая |
||||
ная |
няя |
ческая |
||||
|
|
|
||||
Очень нескоро |
Низкий |
Низкий |
Средний |
Высокий |
Высокий |
|
|
||||||
|
|
|
|
|
|
|
Не очень скоро |
Низкий |
Средний |
Средний |
Высокий |
Высокий |
|
|
||||||
|
|
|
|
|
|
|
Очень скоро |
Низкий |
Средний |
Высо- |
Очень вы- |
Очень высокий |
|
|
кий |
сокий |
||||
|
|
|
|
Очень высокий рейтинг (4) присваивается факторам, требующим немед- |
ленного реагирования, соответственно, самый низкий рейтинг (1) присваивается |
рискообразующим факторам, критичность которых невысока и их наступление |
отложено на длительный срок. |
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · |
Ранжирование факторов риска позволяет команде проекта рас- |
пределить их по категориям опасности последствий проявления: |
рейтинг 4 – рискообразующие факторы, требующие немедленного реагирования;
рейтинг 3 – рискообразующие факторы, реагирование на которые можно выполнить позже;
рейтинг 2 – рискообразующие факторы, требующие дополнительного рассмотрения (включая количественный анализ);
рейтинг 1 – рискообразующие факторы, за которыми в дальнейшем должно проводиться наблюдение.
·· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
6.5.3Стратегии управления рисками
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Процессы планирования мероприятий по реагированию на
риски предполагают выбор стратегии по снижению угроз и разработку планов мероприятий по реализации стратегий. Согласно [14], возможны четыре вида таких стратегий: уклонение от риска, передача риска, снижение риска, принятие риска.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Уклонение от риска предполагает разработку комплекса мероприятий по нейтрализации критических рискообразующих факторов, т. е. изменение плана
115
управления проектом таким образом, чтобы исключить влияние негативных факторов на цели проекта или скорректировать целевые показатели, находящиеся под угрозой, например, отказаться от реализации рискованного функционального требования.
Передача риска подразумевает переложение негативных последствий от проявления рискообразующего фактора на третью сторону (но риск при этом остается), например, заказать разработку рискованного компонента «на стороне». Данная стратегия эффективна для нейтрализации критических рискообразующих факторов, влияющих на бюджет проекта. Условия передачи ответственности третьей стороне должны определяться в контракте (гарантии выполнения контракта, гарантийные обязательства).
Снижение риска предполагает понижение вероятности и/или последствий негативного проявления рискообразующего фактора до приемлемых пределов, например, увеличить сроки выполнения проекта, понизить значения ряда показателей качества ПП. Принятие предупредительных мер по снижению вероятности наступления фактора или его последствий зачастую оказывается более эффективным, нежели действия по устранению негативных последствий, предпринимаемые после наступления события.
Принятие риска предполагается в тех случаях, когда избежать проявления рискообразующих факторов маловероятно и команда проекта не нашла эффективных мероприятий реагирования на риски. Реализация данной стратегии возможна в двух вариантах: активном либо пассивном.
Пассивное принятие данной стратегии не предполагает проведения какихлибо предупредительных мероприятий, оставляя команде проекта право действовать по собственному усмотрению в случае наступления негативных событий. Наиболее распространенной формой активного принятия данной стратегии является создание резерва на непредвиденные обстоятельства в виде возможности привлечения дополнительных финансовых и/или трудовых ресурсов либо корректировки сроков реализации проекта.
По каждому из мероприятий первой группы назначают одного или нескольких ответственных лиц («ответственных за реагирование на риски»), определяются бюджет и сроки выполнения мероприятия. Прошедший экспертизу и утверждений план мероприятий должен быть включен в общий процесс управления изменениями программного проекта.

116
· · · · · · · · · · · · · · · · · · · · · · · · · |
|
Пример · · · · · · · · · · · · · · · · · · · · · · · · · |
|
|
|
Ниже приведены примеры мероприятий, направленных на снижение ряда рискообразующих факторов. Так, например, негативное влияние фактора <не-
полные или нечеткие требования к программному продукту> можно понизить за счет:
изменения стоимости и сроков реализации проекта при каждом добавлении или корректировке требований;
согласования с заказчиком подробного перечня требований и включение этого списка в контракт на разработку ПП;
использования моделей ЖЦ, позволяющих периодическое уточнение требований;
введения буферных работ с соответствующими ресурсами и длительностью выполнения.
·· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Риски, связанные с изменениями ситуации на финансовом рынке, можно
снизить путем внесения в контракт условий, предусматривающих корректировку стоимости проекта в случае кризисных явлений, не зависящих от воли сторон (изменение курса валют). Потери, связанные с ненадежной работой аутсорсинговых компаний, можно избежать путем внесения в контракт пункта о штрафных санкциях за нарушение условий поставки продукта.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Мониторинг и управление рисками представляет собой про-
цесс идентификации, анализа рисков и рискообразующих факторов
ипланирования мероприятий по реагированию на новые риски, отслеживания ранее идентифицированных рисков, а также проверки
иисполнения мероприятий по реагированию на риски и оценке эффективности их выполнения.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
При этом необходимо постоянно решать следующие задачи: пересмотр рисков, аудит рисков, анализ отклонений и трендов.
Пересмотр рисков предполагает регулярную, согласно принятым регламентам, идентификацию, анализ и планирование реагирования на новые риски. Управление рисками проекта должно быть одним из пунктов повестки дня всех совещаний команды проекта.

117
Аудит рисков предполагает изучение и предоставление в документальном виде результатов оценки эффективности выполнения мероприятий по реагированию на риски, требующие немедленного реагирования, изучение основных причин их возникновения.
На основании анализа отклонений и трендов проекта можно прогнозировать на очередной плановый период влияние негативных последствий проявления рискообразующих факторов на цели проекта. Контроль и анализ трендов может повлечь за собой выбор альтернативных стратегий, принятие корректив, перепланировку проекта для достижения базового плана.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Контрольные вопросы по главе 6
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
1.Дайте понятие программного проекта и перечислите его специфические особенности.
2.Приведите определение программного продукта. Перечислите свойства ПП как объекта интеллектуальной собственности.
3.Дайте понятия цели, результата и ограничений программного проекта. Перечислите и прокомментируйте требования к формулировке целей.
4.Раскройте смысл характеристик «железного треугольника» при управлении программными проектами. В чем состоит процедура достижения компромисса между характеристиками?
5.Приведите понятие жизненного цикла программного продукта и назовите стандарты, регламентирующие этапы ЖЦ.
6.Перечислите и прокомментируйте содержание девяти областей знаний стандарта РМВОK.
7.Перечислите и прокомментируйте содержание пяти этапов жизненного цикла программного проекта стандарта РМВОK.
8.Перечислите и прокомментируйте содержание процессов управления программным проектом стандарта ГОСТ Р ИСО/МЭК 12207–2010.
9.Дайте определение и приведите примеры понятий «риск» и «рискообразующий фактор».
10.Приведите пример и прокомментируйте по схеме «условие» – «последствие» – «воздействие» описание внутренних факторов риска программного проекта.
118
11.Приведите пример и прокомментируйте по схеме «условие» – «последствие» – «воздействие» описание внешних факторов риска программного проекта.
12.Раскройте содержание и методы описания показателей вероятности и негативных последствий рискообразующих факторов.
13.Поясните процедуру ранжирования рискообразующих факторов по степени опасности последствий от их наступления.
14.Раскройте содержание модели функциональных зависимостей определения рисков программного проекта.
15.Раскройте содержание стратегий по управлению рисками, приведите примеры конкретных мероприятий по каждой из стратегий.
16.Раскройте содержание этапа мониторинга и управления рисками.