소프트웨어개발 프로세스 성숙 모델 CMMI

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. **

소프트웨어 개발 조직의 역량을 평가하는 성숙도 평가 모델 CMM
소프트웨어 개발 조직의 역량을 객관적으로, 정량적으로 평가하고자 하는 바람

Software Process Improvement가 필요한 이유

소프트웨어는 개발자의 능력, 적용되는 기술, 프로젝트가 얼마나 체계적/효율적으로 진행되는지에 따라 성공이 결정된다.
프로젝트의 성공을 위해서는 프로세스를 개선하려는 노력이 필요하다. (Watts Humphrey - SPI 선구자)

SW-CMM: capability maturity model (성숙도 모델)

첫 시작은 미국 국방성의 Software Engineering Institute (SEI)이다. 소프트웨어로 인한 비용 손실이 너무 커서 만들었다.

→ 안보역량, 국방예산과 직결되는 문제이고 한 번 개발업체 선정 시 쉽게 바꿀 수 없으므로 검증할 수 있는 기준이 필요

여러 모델들이 있지만 가장 널리 쓰이는 것은 CMM이며 현재는 CMMI로 확장되었다. (담당기관: SEI→CMMI institute)

국방성 관련 방산 소프트웨어 개발 업체들에게 반강제로 사용하게 하였는데 써보니 효과가 좋아서 널리 퍼졌다. 

1990년대 초반: 20~30여개 → 2000년대 초반: 400~500여개 → 2018년: 약 3000여개

CMMI Level (staged)

• level1: Initial - 아무것도 안 한 상태
• level2: Repeatable / Managed - 기본적인 핵심역량을 갖추었는지 (Low maturity organization)
  - Configuration Management
  - Measurement and Analysis
  - Project Monitoring and Control
  - Project Planning
  - Process and Product Quality Assurance
  - Requirements Managements
  - Supplier Agreement Management
• level3: Defined - (Low maturity organization)
  - Decision Analysis and Resolution
  - Integrated Project Management
  - Organizational Process Definition
  - Organizational Process Focus
  - Organizational Training
  - Product Integration
  - Requirements Development
  - Risk Management
  - Technical Solution
  - Validation
  - Verification
• level4: Managed - (High maturity organization)
  - Organizational Process Performance
  - Quantitative Project Management
• level5: Optimizing - (High maturity organization)
  - Casual Analysis and Resolution
  - Organizational Performance Management

KPA: key process area

• 각 level마다 정의되어 있음. (level1 제외)
• 해당 level의 KPA를 모두 만족하면 level 인증해줌 (CMMI instituted)
• KPA 별로 Speific Goals (SG)가 존재하는데 이를 모두 달성해야 KPA를 만족했다고 판단함.
  SG를 달성하기 위해선 Specific Practice (SP)에 대한 검사를 받아야 함.

CMMI Continuous Model

Process Management, Project Management, Engineering, Support 등 특정 분야의 성숙도를 측정하는 모델
Stage Model에서 KPA 모두를 만족할 필요 없이 특정 분야의 프로세스 역량만을t개선하는 경우를 위해 정의되었다.

---

CMMI의 효과

많은 회사들이 반복적으로 긍정적인 경험을 했다 - SEI 발표 보고서

Lockheed Martin사의 1992~2002 Level3~Level5 품질 및 생산성 자료
품질 (결함 수): 600 → 51
생산성: 220 → 379
비용 & 일정: 15% → 8%
재작업: 6% → 2%
재사용: 68% → 82%

CMMI의 KeyPoint

1. CMMI에 포함된 KPA는 소프트웨어공학의 Best Practice를 나타낸다. 개념을 이해하고 왜 효과적인지 고민한다
       특히, Level2는 핵심 및 기본 / Level 4와 Level 5는 고급 Practice라고 볼 수 있다.
2. KPA가 제대로 수행되지 않을 경우, 프로젝트에 어떤 일이 있을지 고민해본다. (비전문가의 관점)
3. 프로세스 개선의 목적은 소프트웨어 품질 향상 및 생산성 개선이다. 인증이 목적이 아니다.
4. 프로세스 개선 노력은 장기간에 걸쳐 경영진의 적극적인 지원과 개발자들의 능동적인 참여가 필요하다.
       초기: Level2로 가는데 평균 3년이 걸림 / 현재: 줄어들었지만 22 + 20 + 25 + 13 Month (약 7년)
5. 프로세스 전문가 집단의 도움이 필요하지만, 개발자들의 참여도 필요하다
       프로세스 전문가 그룹을 별도 운영하고, 그 모임에 적극적으로 참여한다 (SPIN)

---

+) KPA별로 정리!

Project Planning

• 체계적인 계획이 있다면 실패 확률과 재작업량이 감소하므로 품질 및 생산성에 많은 영향을 준다
• SG1: 개발비용 및 기간 예측
  - 프로젝트 scope 설정, 노력 및 비용 계산
• SG2: 구체적인 계획
  - 예산 및 일정 제출, 프로젝트 위험 분석, ... 등
• SG3: 필요한 자원이나 인력 확보

 

---

프로젝트 개선을 위해...

이론적인 연구 + 산업체의 사례를 파악하는 것이 중요하다.
조직마다 효율적인 프로세스 개선을 위한 구체적 방법은 다를 수 있으므로 방법을 찾는 노력이 필요하다
- 대기업: 프로세스 전문 인력 고용, 관련 연구 수행 but 개선문화 확산 어려움, 부서마다 문화가 달라 여러 방법이 필요
- 소규모: 자발적 참여 유도 쉬움 but 개선을 위해 많은 비용 투자 어려움, 전문 인력 고용 어려움

산업군에 따라 프로세스 개선 관련 모델은 다를 수 있다. - 소프트웨어 개발 (CMMI) / 자동차 산업 (ASPICE) 

+ CMMI는 현재 미국 외 다른 나라에서 활발히 사용 / 우리나라도 관련 모델 존재함.

 

---

추가 자료 리스트

• report "Permannce Results of CMMI-based Process Improvement" - Gibson, SEI Technical Report (2006)
• Article "Are CMM Program Investments Beneficial? Analyzing Past Studies" - Galin&Avrahami, IEEE Software (2006)