"The readiness is all." - 햄릿 5막 2장 215행
프로젝트는 인생과 같이 불확실합니다. 위험성만을 위해서가 아니라 가능한 경우 위험성을 예상하고 완화하거나, 완화 전략이 부족한 경우 이에 대응하기 위해 위험성을 식별합니다.
위험성은 반복 계획을 가져옵니다. 위험성을 제한하거나 줄이면서 특정 위험성을 처리하도록 반복을 계획합니다. 위험성 목록을 정기적으로 검토하여 위험성 완화 전략의 효율성을 평가합니다. 이를 통해 프로젝트 계획에 대한
개정 및 이후 반복 계획이 수행됩니다.
위험성 관리의 핵심은 해결 방법을 결정할 때 위험성이 현실화(문제점 또는 장애가 됨)될 때까지 기다리지 않는 것입니다. 대륙 횡단 비행 경로에서는 몇 도만 변경되어도 착륙 장소가 크게 달라지는 것과
같이, 위험성을 조기에 관리하면 현실화된 후 정리하는 것보다 비용 및 수고가 덜 듭니다.
다음과 같은 세 가지 기본 전략이 있습니다[BOE91].
-
위험성 방지. 해당 위험성으로 영향을 받지 않도록 프로젝트를 재구성합니다.
-
위험성 이전. 다른 대상(고객, 벤더, 은행, 다른 요소 등)이 위험성을 감수하도록 프로젝트를 재구성합니다. 위험성 방지의 특정 전략입니다.
-
위험성 허용. 비상사태로 위험성을 감수하도록 결정합니다. 위험성 증상을 모니터하고 위험성이 발생한 경우 수행할 작업의 비상사태 계획을 결정합니다.
위험성을 허용하도록 결정한 경우에도 여전히 위험성을 완화하려고 할 수 있습니다. 즉, 해당 영향을 줄이도록 즉각적인 조치 일부를 수행할 수 있습니다.
직접적인 위험성 및 간접적인 위험성 사이를 구별해야 합니다. 간단히 말해, 직접적인 위험성은 어느 정도 제어가 가능한 것이고 간접적인 위험성은 제어가 불가능한 것입니다.
간접적인 위험성은 무시할 수는 없지만 실제로는 거의 중요하지 않습니다. 이 위험성은 변경할 수 없으므로 걱정해도 나아지지 것은 없습니다. 세계가 내일 멸망할 가능성도 있지만 멸망하지 않을
가능성도 있습니다. 그러므로 바로 작업을 시작하는 것이 좋습니다.
때때로 간접적인 위험성은 실제로는 직접적인 위험성이 변장한 것일 수 있습니다. 예를 들어 하나의 컴포넌트 또는 컴포넌트 세트의 외부 공급자 일부에 종속된 경우가 있습니다. 이 경우는 간접적인 위험성으로 나타나지만
이 컴포넌트에 대한 비상사태 계획을 세워 이 위험성을 제어할 수 있습니다. 즉 대체 공급자를 선택하거나 기능을 개발하도록 선택할 수 있습니다. 대부분의 경우 생각보다 더 많은 제어 능력이 있습니다!
간접적인 위험성의 경우 위험성에 대해 어느 정도의 제어를 확보하는 방법을 파악하거나 단순히 위험성을 기록하여 이동시킵니다. 변경할 수 없으므로 고민할 필요도 없습니다.
조직
-
이 프로젝트에 충분히 헌신하고 있습니까(관리, 테스터, QA 및 기타 외부 관련자 포함)?
-
이 조직에서 시도하는 가장 큰 프로젝트입니까?
-
소프트웨어 엔지니어링에 대한 잘 정의된 프로세스가 있습니까? 요구사항 캡처 및 관리가 있습니까?
자금
-
프로젝트를 완료하기 위한 자금이 지원되고 있습니까?
-
훈련 및 조언 활동에 자금이 할당되었습니까?
-
시스템을 고정비로 제공하거나 취소해야 하는 예산 제한사항이 있습니까?
-
비용 예상이 정확합니까?
사람
-
주어진 인원이 충분합니까?
-
적합한 스킬 및 경험이 있습니까?
-
전에 함께 일한 적이 있습니까?
-
프로젝트가 성공할 수 있다고 믿고 있습니까?
-
검토를 수행할 사용자의 대표자가 있습니까?
-
도메인 전문가가 있습니까?
시간
-
스케줄이 현실적입니까?
-
스케줄에 맞게 기능 범위를 관리할 수 있습니까?
-
전달 날짜가 얼마나 중요합니까?
-
"일을 처리할" 시간이 있습니까?
-
경쟁자가 먼저 시장에 진입하는 경우 어떻게 하겠습니까?
-
프로젝트 자금 상태가 위태로운 경우 어떻게 하겠습니까(이 내용을 검토하는 다른 질문은 "무엇이 충분한 자금을 보장할 수 있습니까"임)?
-
시스템의 예상 가치가 예상 비용보다 높습니까? (자본 비용 및 화폐의 시간적 가치를 고려해야 합니다.)
-
주요 공급자와 계약할 수 없는 경우 어떻게 하겠습니까?
-
성공을 측정할 수 있습니까?
-
성공을 측정하는 방법에 대한 합의 내용이 있습니까?
-
요구사항이 매우 안정적이고 이해가 쉽습니까?
-
프로젝트 범위가 확고합니까, 또는 범위가 확장됩니까?
-
프로젝트 개발 시간 스케일이 짧고 확고합니까?
-
기술이 입증되었습니까?
-
재사용 목표가 타당합니까?
-
중간 산출물을 재사용하려면 한 번은 사용해야 합니다.
-
중요한 사항을 변경하지 않고 재사용할 수 있을 정도로 안정적이려면 컴포넌트의 여러 릴리스를 거쳐야 할 수도 있습니다.
-
요구사항에서 트랜잭션 볼륨이 타당합니까?
-
트랜잭션 비율 예상을 신뢰할 수 있습니까? 너무 긍정적입니까?
-
데이터 볼륨이 타당합니까? 현재 사용 가능한 메인프레임을 보유할 수 있습니까, 또는 요구사항으로 워크스테이션이나 부서 시스템이 디자인 파트가 될 것이라고 믿게 된 경우 그 위치에 데이터를 보관할 수
있습니까?
-
프로젝트 팀이 익숙하지 않은 문제점을 해결해야 하는 예외적이거나 힘든 기술 요구사항이 있습니까?
-
성공이 새롭거나 시도되지 않은 제품, 서비스나 기술, 새롭거나 입증되지 않은 하드웨어, 소프트웨어 또는 기법에 의존합니까?
-
인터페이스에 엔터프라이즈 외부에 있는 시스템을 포함하여 기타 시스템에 대한 외부 종속성이 있습니까? 필수 인터페이스가 있습니까, 아니면 인터페이스를 작성해야 합니까?
-
매우 확고한 가용성 및 보안 요구사항이 있습니까(예: "절대 시스템에서 장애가 발생할 수 없음")?
-
시스템 사용자가 개발 중인 시스템 유형에 대한 경험이 없습니까?
-
새 기술 도입 또는 응용프로그램의 복잡도가 커서 위험성이 늘어났습니까?
-
자국어 지원에 대한 요구사항이 있습니까?
-
이 시스템의 디자인, 구현 및 실행이 가능합니까? 일부 시스템은 너무 크거나 복잡하여 올바르게 작업을 수행할 수 없습니다.
-
프로젝트가 기타 (병렬) 개발 프로젝트에 종속되어 있습니까?
-
성공이 기성품 또는 외부에서 개발된 컴포넌트에 종속되어 있습니까?
-
성공이 성공적인 개발 도구(디자인 도구, 컴파일러 등), 구현 기술(운영 체제, 데이터베이스, 내부 프로세스 통신 메커니즘 등)의 통합에 종속되어 있습니까? 이 기술을 사용하지 않고 프로젝트를 제공하는 백업
계획이 있습니까?
경험상, 위험성의 85%는 스케줄에 직접 또는 간접적인 영향을 주므로 내재적으로 비용에도 영향을 줍니다. 5% 정도가 비용에 대한 영향일 수 있습니다. 나머지는 비용 또는 스케줄에 대한 직접적인 영향은 아닙니다.
예를 들어 품질에 대한 영향일 수 있습니다.
최종 기한이 문제인 경우 점진적 전달로 원만하게 접근하십시오. 스케줄을 맞추려고 한 번에 대량으로 전달하지 마십시오.
일부 프로젝트에는 실제로 "엄격한" 최종 기한이 있습니다. 예를 들어 선거 당일 저녁 선거 결과를 "실시간"으로 분석하는 소프트웨어는 선거가 끝나고 한 주가 지나면 가치가 떨어집니다. 또는 여러분은 시작 단계인데
경쟁업체에서 훨씬 나은 소프트웨어를 내놓을 수 있습니다. 갑자기 의욕이 없어지고 어쩔 도리도 없는 상황입니다. 그러나 일반적으로 이렇게 엄격한 최종 기한이 정해진 프로젝트는 소수에 불과합니다. 대부분 지연되면
비용에 영향을 줍니다.
일반적으로 스케줄 확약을 최적의 예상에 타당한 비상사태를 더한 값으로 계산하십시오.
확약 = 예상 + 비상사태
기타 경우 대체 전략과 동일하게 스케줄 예상을 설정하도록 권장하기도 합니다. 즉, 이 예상은 비상사태 계획에 기반하는 것입니다. 그러나 실제로 모든 위험성이 실현되는 것이 아니므로 너무 비관적인
방법입니다.
스케줄 위험성은 일부 예상 및 비용 도구로 통합됩니다. 예를 들어 COCOMO 모델에서 많은 가격 요인은 다음과 같습니다.
-
복잡도(cplx)
-
실시간 제한조건(time)
-
저장영역 제한조건(stor)
-
경험(Vexp)
-
좋은 도구의 가용성(tool)
-
스케줄 압박(sced)
위의 항목이 실제 위험성 요소입니다.
위험성 관리에 대한 보다 복잡한 기법은 Monte Carlo 시뮬레이션 사용과 관련이 있습니다. 이 시뮬레이션에서는 시뮬레이션 도구를 통해 상당히 많은 "시나리오"를 실행하여 전반적인 위험성 및 비상사태를
계산합니다[KAR96].
|