위험 분석과 위험 완화의 차이점과 (코딩 전 또는 코딩 이후) 누가 소프트웨어 개발 수명주기에서 수행해야하는지 (QA/분석가/개발자)는 무엇입니까?위험 분석과 위험 완화의 차이점은 무엇입니까?
의견, 링크 또는 문서 템플릿이 유용 할 것입니다.
편집 나는 미드의 의견에 따라 경우
"톰 드 마르코에 따르면 - 리스크 관리는 성인을위한 프로젝트 관리는"
그에게 필요하지 않은 기존의 SDLC의 일부 지역을 의미 하는가를 뒤따라야 할까? 어느 부분? 즉. 위험 관리가 일반적인 SDLC의 어떤 측면을 대체합니까? 많은 MS 프로젝트 훈련이 필요하지 않습니까?
위험 분석은 프로젝트에서 발생할 수있는 위험의 유형, 확률 및 심각도를 식별하는 계획 프로세스입니다. 일반적으로 프로젝트 관리자는 엔지니어와 품질 팀의 의견을 바탕으로이를 구축합니다.
위험 완화는 위험 분석으로 식별 된 위험에 대해 수행 할 계획입니다. 여기에는 다음 중 하나의 계획을 포함 할 수 있습니다.
가) 위험 회피 : 위험을 야기 할 가능성을 최소화합니다. 위험한 일을하지 말고 즉각적인 구성 요소 또는 소프트웨어 패키지를 구입합니다.
B) 결과의 완화 : 위험이 발생할 경우 위험 요소의 심각성 최소화 (비상 계획 수립, 추가 시간 및/또는 예산 추가, 전체 백업 수행 등); 위험 요소 : 위험 요소가 발생할 때 위험을 감당할 준비가되어 있어야합니다 (위험 요소에 대한 위험이 낮거나 낮을 경우 관리 비용과 비교해 볼 때 가치가 없을 수도 있습니다. 유일한 개발자이고 소행성에 치일 확률이 있습니다. 단순히 위험을 감수할만한 가치가있을 수 있습니다).
D) 위험 요소 전수 : 다른 사람이 보험 회사 또는 외주 제공 업체와 같이 귀하를보다 잘 처리 할 수있는 위험을 부담하게하십시오.
계획은 일반적으로 프로젝트 관리자가 조정하고 팀의 모든 사람이 구현합니다.
위험 분석, 위험 완화 및 위험 모니터링은 위험 관리 프로세스를 구성합니다. 거의 모든 프로세스와 마찬가지로 지속적인 활동이기 때문에 프로젝트 전체에서 수행해야합니다.
일반적으로 위험 분석은 무엇이 잘못 될지 알아볼 것입니다. 위험 완화는 무엇인가 잘못되었다는 상황에서 취해야 할 조치입니다.
두 가지 모두 처음부터 완료되어야합니다. 일반적으로 프로젝트를 완료하면 비즈니스에 도움이되는지 확인하기 위해 수행됩니다. (위험 대 보상)
위험 분석 = 현재 워크 플로 또는 활동 순서에 따라 취할 수있는 위험 요소입니다. 기술적이거나 그렇지 않을 수도 있습니다. 또한 시나리오에 따라 일련의 문제가 발생할 위험 (확률에 따라)은 무엇이라고 말할 수 있습니다.
위험 완화 (Risk Mitigation) = 위험 요소의 영향을 최소로 유지하기 위해 따라야하는 체계적으로 추론 된 단계입니다. 미확인 위험은 완화하기가 어렵습니다.
일반적으로 위험 분석은 위험 요소가 있는지, 위험 요소가 어떤 영향을 미치는지, 발생 가능성 및 발생시기를 결정합니다. 위험 완화는 위험을 완전히 줄이거 나 제거하려고 시도하고 있으며이를 수행하기위한 다양한 수단이 있습니다.
위험은 프로젝트 라이프 사이클 전반에 걸쳐 지속적으로 검토되어야합니다 (예 : 위험이 증가 할 가능성이 있으므로 (예 : 3 개월 동안 제공되지 않는 타사 구성 요소에 의존하므로 위험하지 않음). 3 개월 선까지 올라가고 공급자로부터 아무 것도 듣지 않으면 훨씬 더 위험합니다), 자연적으로 감소하거나 사라집니다.
누가 실제로 위험을 분석하고 완화하는지는 누가 가장 적절한 지에 따라 크게 좌우됩니다. 소프트웨어와 관련이있는 경우 위의 예와 같이 소프트웨어 개발자가 모니터링,보고 및 작업하도록 할당 된 경우 일 수 있습니다. 물론 그것은 프로젝트 관리자 또는 프로젝트 품질 보증을하는 사람이 될 수도 있습니다.
일반적인 규칙은 자주 분석하고, 지속적으로 모니터링하며, 위험을 줄이기 위해 가장 적합한 사람을 지정합니다.
이것은 프로젝트 과정에서 계속됩니다. 최소한 반복 할 때마다 수행해야합니다 (몇 주간 만 가능합니다). 방법론 및 방법에는 소프트웨어 개발과 관련된 모든 위험 요소를 완화하기위한 여러 가지 방법이 있습니다.
저는 DeMarco의 진술에 동의합니다 : "위험 관리는 성인을위한 프로젝트 관리"입니다. PM으로서 우리는 훌륭한 거버넌스와 리스크 관리의 이유로해야 할 일을합니다. 그들 없이는 프로젝트는 단지 사람들의 무리 일뿐입니다.
위험 관리는 SDLC의 일부 또는 일반적인 방법을 대체하지 않습니다. 그것은 당신이 지루한 스케쥴링, 레지스터 및 문서 작업을하는 이유입니다. 당신은 부정적인 위험의 영향을 줄이고 모든 기회 (즉, 긍정적 인 위험)를 활용하기 위해 이러한 일을합니다.
위험 요소 등록을위한 템플릿에서 조직은 위험 요소에 따라 표준을 설정해야합니다. 다음은 매우 간단한 프로세스를 설명합니다.
1) 먼저 위험 요소 목록의 각 위험 요소를 Excel의 목록으로 식별합니다.
2) 다음은 각 위험 요소를 'impact 및 probability으로 판단합니다.
3) 영향 가능성의 조합 다음에) 위험 의 레벨 (제 행렬 표를 참조)
4)이 극한에 (저이 리스크 레벨을 사용을 설명 귀하의 접근 방식을 설명하십시오. 내 예에서는 governance prescribed 수준이 회사에서 지정합니다. )
5가에서을 (두 번째 표 참조), 또는 다른 사람이 다음 @JohnFx 대답에 따라 당신의 레지스터의 각 위험에 대해 취해야 할 대응을 결정한다. 당신이 PM이고 낮은 위험성이 있다면 .. "수용"이 올바른 접근법 일 것입니다. 위험 관리 및 거버넌스의 개념은 이것을 작성하고 이해 관계자에게 명확하게 전달하는 것입니다. 그렇다면 왜 당신은 무엇을하고 있는지 알 수 있습니다.
나는 정기적으로 스폰서와 팀과의 상위 5 가지 위험에 대해서만 논의하지만 전체 위험 요소 등록은 프로젝트 전체에서 정기적으로 세미나 검토해야합니다. 그냥 서랍에 넣지 마십시오. 특정 의사 결정을 내리고 특정 조치를 취한 이유에 대한 커뮤니케이션 도구가 될 수 있으며 항상 최신 상태로 유지되어야합니다.
주의 : 이들은 정량적 인 위험 평가 기술이며,보다 진보 된 정량 기법이 있습니다. 그러나 그것이 더 복잡하다는 이유만으로 더 나아진 것은 아닙니다. 식욕, 예산 및 능력에 따라 장소가 다릅니다.
숙제가 있습니까? – JohnFx
재밌 네요, 아니, 회사가 "숙제"를 줄 수 있다고 생각하지 않는 한, 당신이 옳다면, 우리가하는 일을 왜 생각하는지 숙제입니다. 어쨌든 훌륭한 대답입니다, "Tom DeMarco - 위험 관리는 성인을위한 프로젝트 관리입니다 - 미드 "는 지금까지 최고의 IMO입니다. 덕분에 –