В чем разница между анализом рисков и уменьшением рисков?

Question

В чем разница между анализом рисков и уменьшением риска и когда (до кодирования или после кодирования?) И кем (QA/аналитик/разработчик?) Должны выполняться в Жизненном Цикле разработки программного обеспечения?

Мнения, ссылки или шаблоны документов были бы полезными.

---

EDIT Если я следую за комментарием Мид:

«По словам Тома Демарко - Управление рисками является Управлением проектов для взрослых»

, что значит ли некоторые части традиционного СДЛКА не нужно следовать? Какие части? то есть. какие аспекты типичного SDLC заменяют управление рисками? Нет необходимости в таком количестве тренировок MS?

Answer 1

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

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

A) Устранение риска: минимизировать потенциал для возникновения этих рисков (не делая рискованных действий, т. Е. Покупая готовый компонент или программный пакет);

B) Смягчение последствий: свести к минимуму степень риска, если они произойдут (иметь план на случай непредвиденных обстоятельств, добавлять дополнительное время и/или бюджет, делать полные резервные копии и т. Д.); и (или)

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

D) Передача риска: пусть кто-то другой несет риск для вас, кто-то, кто может справиться с этим лучше, то есть страховая компания или сторонний поставщик.

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

Общее правило часто анализируется, постоянно контролируется и назначает лучшего человека для снижения риска.

Answer 5

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

Answer 6

Я согласен с заявлением DeMarco: «Управление рисками - это управление проектами для взрослых». Как премьер-министр, мы делаем то, что делаем по соображениям хорошего управления и управления рисками. Без них проект - это всего лишь куча людей, которые делают вещи.

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

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

1) Сначала вы определяете каждый риск в Регистре рисков, который является просто списком в Excel.

2) Далее вы оцениваете каждый риск «impact» и «probability».

3) Сочетание воздействия и вероятности затем описать уровень риска (см первой таблицы матрицы)

4) использование этого уровня риска (от низкого до крайности) к помогите сфокусировать свой подход. В моем примере уровень governance prescribed указан компанией. (см вторую таблицу)

5) Из того, что вы или кто-то другой будет решить, какой ответ принимать для каждого риска в вашем реестре, как за @JohnFx ответ. Если вы являетесь премьер-министром, и это низкий риск, тогда «принятие» может быть правильным подходом. Концепция управления рисками и управления заключается в том, что вы пишете это и четко сообщаете об этом своим заинтересованным сторонам. Тогда вы все знаете, почему и что вы делаете.

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

NB: Это качественные методы оценки риска, есть более совершенные количественные методы .. но только потому, что они сложнее, это не значит, что они лучше. Они имеют свое место в зависимости от аппетита, бюджета и возможностей.