[소프트웨어공학] 5장. 프로젝트 관리 (2)

5장. 프로젝트 관리 (2)

---

[ 리스크 관리 ]

Risk 특징 : concerns future happenings (미래의 일에 관한 것)

Risk analysis(분석)

• identification(식별)
• projection/estimation (추정)

Risk resolution - RMMM

• mitigation (완화)
• monitoring (감시)
• management/control (통제)

 

< Risk Identification (식별) >

1. PS - Product Size
2. 구축 또는 수정할 소프트웨어의 전체 크기와 관련된 위험.
3. BU - Business Impact
4. 경영자 또는 시장에 의해 부과되는 제약과 관련된 위험.
5. CU - Customer Characteristics
6. 고객의 정교함 및 고객과 적시에 의사 소통하는 개발자의 능력과 관련된 위험.
7. PD - Process Definition
8. 소프트웨어 프로세스가 정의되고 개발 조직이 따르는 정도와 관련된 위험.
9. DE - Development Environment
10. 제품 구축에 사용할 도구의 가용성 및 품질과 관련된 위험.
11. TE - Technology to be built
12. 구축될 시스템의 복잡성 및 시스템에 의해 패키지되는 기술의 "신기함"과 관련된 위험.
13. ST - Staff size and experience
14. 작업을 수행할 소프트웨어 엔지니어의 전반적인 기술 및 프로젝트 경험과 관련된 위험.

< Risk Projection (추정) >

위험이 실제일 가능성, 위험과 관련된 문제의 결과

There are four risk projection steps:

• establish a scale that reflects the perceived likelihood of a risk
• delineate the consequences of the risk
• estimate the impact of the risk on the project and the product,
• note the overall accuracy of the risk projection so that there will be no misunderstandings.

Risk Table 구조

< RMMM >

Mitigation 완화 — how can we avoid the risk?

Monitoring 감시 — what factors can we track that will enable us to determine if the risk is becoming more or less likely?

Management 관리 — what contingency plans do we have if the risk becomes a reality? → e.g., “knowledge transfer mode”

For large project, 30-40 risks are identified

 

Pareto 80-20 rule : shows that 80% of risk are in 20% of identified risk.

이태리 경제학자 Pareto가 1900년대 만든 법칙

예: “스마트폰 사용자의 20%가 전체 통화량의 80%를 쓴다.”

 

[ Maintainability (보수유지성) ]

기존 SW의 용이성에 대한 질적 표시

• Corrected - 오류수정
• Adapted - 환경적응
• Enhanced - 기능강화