лекция. Сборник лекций по МДК _Технология разработки программного обеспе. Курс лекций для специальности спо базовой подготовки

• Название: Курс лекций для специальности спо базовой подготовки
• Анкор: лекция
• Дата: 02.09.2022
• Размер: 4.41 Mb.
• Имя файла: Сборник лекций по МДК _Технология разработки программного обеспе.docx
• Тип: Курс лекций; #660044
• страница: 37 из 62

Анализ требований и управление рисками

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

Управление риском - комплекс мероприятий по выявлению, оценке, предотвращению и контролю рисков проекта.

Как пишет К.Вигерс [15.5], "Если что-либо нехорошее уже произошло с вашим проектом, то это - проблема, а не риск… Управление риском означает работу с потенциальной опасностью до того, как она перейдет в кризисную фазу". Менеджеры проектов должны выявлять риск и управлять им, начиная с факторов, связанных с требованиями, в сотрудничестве с представителями Заказчика.

Стратегии и работы по управлению риском

Управление риском включает в себя действия, показанные на рис. 15.1 [15.5].



Рис. 15.1.

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

Так, все риски принято делить на прямые (те, на которые Разработчик может так или иначе влиять) и косвенные (независимые от Разработчика) [15.6].

М. Фаулер [15.7] предложил разделить все риски на четыре категории:

• 
  риски, связанные с требованиями,
  
• 
  технологические риски,
  
• 
  риски, связанные с квалификацией персонала,
  
• 
  политические риски.
  

Распространенные факторы риска, связанные с требованиями, включают неверное понимание требований, недостаточное вовлечение пользователей, неточности или изменения в масштабах и целях проекта, постоянно нестабильные требования. Подробный анализ этих видов рисков можно найти в [15.5], глава 23.

Анализ риска сводится к исследованию и описанию потенциальных последствий конкретных факторов риска для проекта, а также вероятности их проявления.

Определение приоритетов состоит из поиска ответов на два вопроса: насколько вероятно проявление риска в проекте; насколько разрушительны могут быть последствия его проявления.

Обнаруженные риски помещаются в специальный документ - risk list.

Существуют три основные стратегии поведения в отношении рисков:

Предотвращение риска, передача риска, принятие риска.

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

Передача риска - перераспределение работ проекта таким образом, чтобы кто-то другой (Заказчик, партнер и т.п.) отвечал за работу с ним.

Принятие риска обязывает Разработчика "заботиться" о нем. Мероприятия по контролю риска (risk control) включают планирование, разрешение и мониторинг.

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

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

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

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