위험관리 절차

위험 관리는 소프트웨어 개발에 방해가 되는 요소를 파악하고(위험 요소 식별), 위험 요소의 발생 확률과 영향도를 평가한 뒤(위험 분석), 분석한 결과에 따라 위험 우선순위를 정하여 그에 맞게 대책을 세우는 것이다.
이러한 위험 관리 절차는 [그림 3-18]과 같다.

그림 3-18 위험 관리 절차

각 절차별로 하나씩 살펴보자.

1.위험 요소 식별

위험 관리에서 가장 중요한 일은 프로젝트 수행에 영향을 주는 위험 요소를 파악하는 것이다.
일단 위험 요소를 찾아내야 예방하거나 최소화하는 등 여러 대안이 나올 수 있다.

위험 요소를 찾는 방법에는 팀원들이 모여 발생 가능한 위험 요소에 대해 브레인스토밍해서 도출하는 방법과 이전에 유사한 프로젝트를 진행할 때 발생한 위험 요소를 참조하는 방법이 있다.
이때는 경험 많은 개발자들의 의견을 듣는 것도 매우 중요할 것이다.

위험 요소를 찾는 것이 가장 우선적으로 이루어져야 하지만, 찾은 위험 요소의 원인을 규명하는 일도 해결책을 강구하는 데 매우 중요하다.
그러므로 위험 요소 식별 과정에서 위험 요소를 찾고 원인도 알아내야 한다.

그렇다면 어떤 위험 요소가 있고 그 원인은 무엇일까? 대표적인 것이 개발자들의 이직이다. 전자 제품 개발 등과 달리 소프트웨어 개발은 사람이 중심이다.
그러므로 개발 도중에 유능한 개발자가 이직하면 일정에 상당한 차질이 생긴다. 새로운 개발자를 바로 투입한다고 해결될 문제도 아니다.

그러면 개발자가 이직하는 원인을 찾아보고 대책을 세워야 할 것이다. 이직 이유는 다양하겠지만 급여 문제, 과중한 업무, 팀원 내의 관계 문제 정도가 가장 큰 원인으로 꼽힐 것이다.
관리자는 프로젝트 진행 중에 이직 문제가 발생하지 않도록 평소에 개발자들과 충분히 대화하여 개발자들의 고민을 알고 있어야 한다.

또 요구 사항의 변경도 개발 일정에 영향을 준다. 설계와 구현은 완료된 요구 분석 명세서를 기준으로 작업하는데, 요구 사항이 계속 변하고 점차 증가하면 예상보다도 더 많은 영향을 줄 수 있다.
요구 사항이 계속 변경되거나 추가되는 원인은 요구 사항 파악 단계에서 시간을 많이 할애하지 못해 사용자와 충분한 대화를 나누지 못했거나 요구 사항을 잘못 파악했기 때문이다.
그렇다면 계획 단계에서 요구 사항 파악 시간을 충분히 확보해야 할 것이다.
그리고 유사한 프로젝트를 많이 경험한 분석가를 투입하여 사용자의 요구보다 더 앞서 새로운 기능들을 제공해야 할 것이다.

이처럼 프로젝트에 직·간접적으로 영향을 미칠 수 있는 요소를 찾아내는 작업이 위험 요소 식별 단계이다. [표 3-23]은 프로젝트 수행 시 일반적으로 발생할 수 있는 위험 요소이다.

표 3-23 프로젝트 수행 시 발생할 수 있는 위험 요소

2.위험 분석

위험 요소를 식별했다면 그 위험 요소가 발생할 가능성과 영향력을 판단해야 한다.
이는 쉬운 일이 아니므로 과거 프로젝트에서 데이터와 위험을 분석한 경험이 많은 개발자에 의존해 판단하게 되는데, 이 과정이 바로 위험 분석이다.

위험 발생 가능성의 척도는 '매우 낮음(〈10%), 낮음(10~25%), 보통(25~50%), 높음(50~75%), 매우 높음(〉75%)'과 같은 등급으로 분류할 수 있다.
또는 프로젝트 진행 중 '위험 발생 확률이 80% 이상이면 상, 30~80%이면 중, 30% 미만이면 하'와 같이 세 단계로 분류할 수도 있다.
또 영향력은 재앙, 심각함, 해결 가능함, 경미함 등으로 분류하기도 하고, '비용과 일정이 20% 이상 초과하면 상, 5~20%이면 중, 5% 이하이면 하'로 나눌 수도 있다.

도출된 위험 요소에 대한 가능성과 영향력을 등급으로 나타냈다면 이를 이용해 어떤 위험이 가장 중요한지 순위를 정한다.
당연히 발생 확률도 높고 영향력도 크면 1순위가 되고 발생 확률이 가장 낮고 영향력도 매우 미비하다면 순위가 가장 낮을 것이다.

3.위험 계획 수립

위험 계획 수립은 식별된 위험 요소의 위험을 관리하기 위해 전략을 찾는 과정이다.
위험 원인을 파악하는 일은 위험 요소 식별 과정에서 진행되므로 이 과정에서는 특히 위험을 처리하는 위험 대응 방안을 잘 세워야 한다.
예를 들어, 요구 사항이 계속 변경되면 고객과 그 문제를 재협의할 수도 있고, 고객 입장에서 개발비가 많다고 하면 금년의 개발 범위를 줄이고 연차적으로 개발하는 방법을 제시할 수도 있다.

4.위험 감시

위험 요소가 식별되었다고 문제가 해결되진 않는다. 식별된 위험은 특별히 계속 감시해야 한다.
즉 식별된 위험 요소의 발생 확률과 변화 등을 관리해야 할 것이다.
따라서 프로젝트가 종료되면 시작 시 예측한 위험 요소가 실제로 얼마나 발생했는지, 위험에 대한 대응 방안이 실제 발생했을 때 적절했는지 등을 평가하고, 앞으로 유사한 프로젝트를 진행할 때 참고할 수 있도록 개발사 내의 데이터베이스에 기록해놓아야 한다.

https://m.terms.naver.com/entry.nhn?docId=3532919&cid=58528&categoryId=58528