가이드라인: 위험 목록
주제
"The readiness is all(각오가 되어있어 야지)." - Hamlet V:ii:215
인생과 마찬가지로 프로젝트도 불확실합니다. 위험 자체가 아니라 가능한 위험을 예상하여 위험을 완화시키기거나
완화 전략이 충분하지 않으면 위험에 대응할 수 있도록 위험을 식별합니다.
반복이 특정 위험을 검토하거나 위험을 제한하거나 줄이려는 시도로 계획되므로 위험에 따라 반복 계획을
추진합니다. 위험 목록은 위험 완화 전략의 효과를 평가하기 위해 주기적으로 검토되며, 그 다음으로 프로젝트
계획 및 후속 반복 계획의 개정이 추진됩니다.
위험이 구체화되고 문제 또는 장애가 되어 해당 조치를 결정할 때까지 대기하지 않는 것이
위험 관리의 핵심입니다. 마치 대륙 횡단 비행 경로를 약간 변경하면 항공기 착륙 지점에 상당한 영향이 미치는
것처럼 초기에 위험을 관리하면 거의 항상 위험이 발생한 후 정리하는 것보다 비용과 수고를 덜 들일 수 있습니다.
다음과 같이 세 가지 주요 전략이 있습니다[BOE91].
- 위험 회피 - 해당 위험이 영향을 미칠 수 없도록 프로젝트를 재구성합니다.
- 위험 이전 - 관계자 또는 그 밖의 다른 요소(고객, 벤더, 은행, 기타 요소 등)가 해당 위험을
부담하도록 프로젝트를 재구성합니다. 위험 회피의 특정 전략입니다.
- 위험 인수 - 우발적 사건으로서 위험과 함께 지속되도록 결정합니다. 위험 증상을 모니터하고
위험이 발생하는 경우 비상 조치 계획을 결정합니다.
위험을 허용하도록 결정하는 경우에도 위험을 완화시킬 수 있습니다. 즉, 즉각적인 조치를 수행하여
영향을 줄일 수 있습니다.
직접 위험과 간접 위험 사이를 구별해야 합니다. 간단히 말하자면 직접 위험은 어느 정도 제어할 수 있지만 간접 위험은 제어할 수 없습니다.
간접 위험을 무시하지 않아야 하지만 이러한 위험은 실제로 거의 중요하지 않습니다. 즉, 이 위험은 변경할 수 없으므로 걱정한다고 해서 얻어지는 것이 거의 없습니다. 내일 세계가 종말한다라는 것이 사실일
수도 있지만, 종말이 오지 않을 수도 있으므로 현재 작업에 충실하는 것이 좋습니다!
때때로 간접 위험을 가장한 직접 위험이 실제로 존재할 수 있습니다. 예를 들어, 한 컴포넌트 또는 컴포넌트 세트를
외부 공급자에 의존할 수 있습니다. 이 경우는 간접 위험으로 나타나지만 해당 컴포넌트의 비상 계획을 갖추고 있으면
이러한 위험을 관리할 수 있습니다. 즉, 대체 공급자를 선택하거나 기능을 자체적으로 개발하도록 선택할 수
있습니다. 다수의 경우에서 생각 이상으로 더 많이 관리하게 됩니다!
간접 위험의 경우 해당 위험을 어느 정도 관리할 수 있는 방법을 이해해야 하거나 이 위험을 확인한
다음 작업 진행해야 합니다. 변경할 수 없는 위험에 대해 고민할 필요는 거의 없습니다.
조직
- 이 프로젝트에 대한 충분한 확약(관리자, 테스터, QA 및 기타 외부 관계자 포함)이 있습니까?
- 지금까지 조직이 수행한 가장 큰 프로젝트입니까?
- 정의가 명확한 소프트웨어 엔지니어링 프로세스가 있습니까? 요구사항 캡처 및 관리 프로세스가 있습니까?
자금 조달
- 프로젝트를 완료하기 위한 자금 조달이 원활합니까?
- 훈련 및 모니터링에 자금 조달이 할당되었습니까?
- 시스템이 고정 비용으로 납품되거나 취소될 경우와 같은 예산 제한이 있습니까?
- 비용 추정값이 정확합니까?
인력
- 사용 가능한 충분한 인력이 있습니까?
- 적합한 기술과 경험을 갖추고 있습니까?
- 이전에 공동 작업의 경험이 있습니까?
- 프로젝트가 성공할 수 있다고 확신합니까?
- 검토에 참여할 수 있는 사용자 대리인이 있습니까?
- 사용 가능한 도메인 전문가가 있습니까?
시간
- 현실적인 스케줄입니까?
- 스케줄을 맞추도록 기능의 범위가 관리될 수 있습니까?
- 납품 일자가 어느 정도 중요합니까?
- "올바른 처리"를 위한 시간이 있습니까?
- 경쟁자가 시장을 먼저 차지하면 어떻게 하겠습니까?
- 프로젝트 자금 조달이 어려울 경우 어떻게 하겠습니까("무엇이 충분한 자금 조달을
보장할 수 있습니까?"라고 다른 방법으로 질문할 수 있습니다)?
- 계획된 시스템 가치가 계획된 비용보다 큽니까? (반드시 화폐의 시간 가치와 자본 비용을 설명해야 합니다.)
- 핵심 공급자와 계약할 수 없으면 어떻게 하겠습니까?
- 성공을 측정할 수 있습니까?
- 성공 측정 방법에 관한 합의가 있습니까?
- 요구사항이 매우 안정되고 쉽게 이해됩니까?
- 프로젝트 범위가 확고하거나 계속 확장되고 있습니까?
- 프로젝트 개발 시간이 짧고 유연성이 없습니까?
- 입증된 기술을 보유하고 있습니까?
- 재사용 목표가 합리적입니까?
- 결과물은 한 번 사용하고 나서야 재사용할 수 있습니다.
- 여러 릴리즈의 컴포넌트를 사용하고 나서야 중요한 변경 없이 재사용할 만큼 충분히 안정될 수 있습니다.
- 요구사항의 트랜잭션 볼륨이 합리적입니까?
- 트랜잭션 처리율 추정값을 신뢰할 수 있습니까? 매우 낙관적입니까?
- 데이터 볼륨이 합리적입니까? 이 볼륨을 현재 사용할 수 있는 메인프레임에서 보유하거나 워크스테이션
또는 부서 간 시스템이 설계의 일부분이라고 믿도록 하는 요구사항인 경우 데이터를 이러한 시스템에 합리적으로
보유할 수 있습니까?
- 프로젝트 팀이 생소한 문제에 당면하게 하는 예외적이며 까다로운 기술 요구사항입니까?
- 새롭거나 시도되지 않은 제품, 서비스, 기술 또는 새롭거나 증명되지 않은 하드웨어, 소프트웨어 또는 기술에
따라 성공 여부가 달라집니까?
- 엔터프라이즈 외부 시스템을 포함하여 다른 시스템에 대한 인터페이스에 외부 종속성이 있습니까? 필요한
인터페이스가 있거나 작성해야 합니까?
- 크게 유연하지 못한 사용 가능성 및 보안 요구사항입니까(예: "전혀 실패할 수 없는 시스템")?
- 사용자가 개발 중인 시스템의 유형에 익숙하지 않습니까?
- 어플리케이션의 위험이나 규모 또는 새로운 기술로 인해 위험이 늘어났습니까?
- 자국어 지원에 대한 요구사항이 있습니까?
- 이 시스템을 설계, 구현 및 실행할 수 있습니까?
일부 시스템은 너무 크거나 복잡하여 제대로 작동할 수가 없습니다.
- 프로젝트가 다른 동시 진행 개발 프로젝트에 종속됩니까?
- 재고품 또는 외부 개발 컴포넌트에 따라 성공 여부가 달라집니까?
- 개발 툴(설계 툴, 컴파일러 등)과 구현 기술(운영 체제, 데이터베이스, 프로세스 간 통신 메커니즘 등)의
통합에 따라 성공 여부가 달라집니까? 이러한 기술을 사용하지 않는 프로젝트를 인도하기 위한 백업 계획이 있습니까?
경험에 따르면 위험 중 85%가 스케줄에 직접적이거나 간접적인 영향을 미치고 있으며 이에 따라 비용에도
암시적으로 영향을 미치는 것으로 밝혀졌습니다. 대략 5%만이 비용 영향을 받습니다. 나머지 위험은 비용 또는 스케줄에
직접적 영향을 주지 않지만 다음 예에서는 품질에 영향을 줍습니다.
최종 기한까지 여유가 없는 경우 점진적 납품으로 최종 기한에 유연하게 접근하십시오.
스케줄 작성을 시도할 경우 한 번에 대량 납품은 피하십시오.
일부 프로젝트에는 실제로 "상당히 여유가 없는" 최종 기한이 있습니다. 예를 들어, 선거일 밤에
선거 결과를 "실시간"으로 분석하는 소프트웨어는 선거 이후 한 주가 지나면 가치가 거의 없습니다. 또는
자신의 소프트웨어가 경쟁자의 소프트웨어보다 뒤처질 수 있습니다. 즉, 자신은 아직도 제품을 개발 중에 있지만 경쟁자는
더 나은 제품을 출시하고 있는 경우입니다. 그러면 바로 게임을 더 이상 진행할 수 없으며 많은 것을 포기해야만
합니다. 그러나 일반적으로 이처럼 여유가 없는 최종 기한을 가지는 프로젝트는 거의 없습니다. 대부분 경우
지연은 비용에 영향을 미칩니다.
일반적으로 스케줄 확약을 최상의 추정과 어느 정도 합리적인 비상 상황을 합한 값과 같게 하십시오.
확약 = 추정 + 비상 상황
설정 중인 스케줄 기대값이 대체 전략과 같도록 하는 것이 좋습니다. 즉, 비상 계획에 기반하여 해당 기대값을 작성하도록 권장하지만 모든 위험이 실제로 구체화되는 것은 아니기 때문에 이 방법은 그리 낙관적이지 못합니다.
스케줄 위험은 일부 추정 및 비용 툴에서 통합됩니다. 예를 들어, COCOMO 모델에서 다수의 원가 동인은
다음과 같습니다.
- 복잡도(cplx)
- 실시간 제한조건(time)
- 저장영역 제한조건(stor)
- 경험지수(Vexp)
- 유용한 툴의 사용 가능성(tool)
- 스케줄 여유 정도(sced)
상기 사항은 실제로 위험 요소가 됩니다.
매우 정교한 위험 관리 기술에서는 시뮬레이션 툴을 통해 다수의 "시나리오"를 실행하여 전반적인 위험과
비상 상황을 산출하는 Monte Carlo 시뮬레이션을 사용합니다[KAR96].
|