| 목차 |
|---|
CMMI
Capability Maturity Model Integration, 능력 성숙도 모델 통합
Carnegie Mellon University 연구진이 개발
미국 국방성(DoD)에서 소프트웨어 외주 업체를 선정할 때 "이 회사가 믿고 맡길 만한 프로세스를 갖췄나?"를 평가하기 위해 만든 기준
https://ko.wikipedia.org/wiki/능력_성숙도_통합_모델
https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration
| 성숙도 | 단계 | 약약어 | 주요 문서 | 추가되는 핵심 의미 |
|---|---|---|---|---|
| Level 2 (Managed) | 프로젝트 관리 | SPP, SRS, SCMP, SQAP | 프로젝트 계획서, 요구사항 명세서, 형상/품질 계획서 | "프로젝트별 관리"가 핵심. 개별 프로젝트가 통제되고 있는지 확인 |
| Level 3 (Defined) | 공정 표준화 | OSSP, SDD, STD, V&V | 조직 표준 프로세스, 설계서, 테스트 기술서, 검증/확인 보고서 | "조직 차원의 표준"이 핵심. 모든 프로젝트가 공통된 매뉴얼에 따라 수행됨 |
| Level 4 (Quantitatively) | 정량적 관리 | PPB, PPM | 프로세스 성능 베이스라인, 정량적 관리 보고서 | "통계적 데이터"가 핵심. 숫자로 프로세스의 안정성을 예측함 |
| Level 5 (Optimizing) | 지속적 개선 | CAR, DAR | 원인 분석 보고서, 의사결정 분석 보고서 | "결함 예방과 혁신"이 핵심. 스스로 문제를 찾아 프로세스를 최적화함 |
CMMI 기반 요구사항 세분화 및 개발 문서 체계
| 순서 | 성숙도 | 약어 | 영어 풀네임 | 한국어 명칭 | 주요 내용 및 포함 단계 |
|---|---|---|---|---|---|
| 1 | L2 | URS | User Requirement Specification | 사용자 요구사항 명세서 | 고객의 비즈니스 언어로 작성된 요구사항. 개발의 최상위 기준점 |
| 2 | L3 | SyRS | System Requirement Specification | 시스템 요구사항 명세서 | 하드웨어, 소프트웨어, 인력을 포함한 전체 시스템 관점의 요구사항 |
| 3 | L3 | SyDS | System Design Specification | 시스템 설계서 | 시스템 요구사항을 기반으로 한 전체 시스템 구조(Architecture) 설계 |
| 4 | L2 | SRS | Software Requirement Specification | 소프트웨어 요구사항 명세서 | 시스템 요구사항 중 '소프트웨어'가 구현할 기능을 상세 기술(L2 필수) |
| 5 | L3 | SDD | Software Design Description | 소프트웨어 설계서 | SRS를 기반으로 한 모듈, 인터페이스, DB 등 소프트웨어 상세 설계 |
| 6 | L2 | SPP | Software Project Plan | 프로젝트 계획서 | 요구사항 규모에 따른 일정, 예산, 인력 계획 (L2 핵심) |
| 7 | L2 | RTM | Requirements Traceability Matrix | 요구사항 추적표 | URS → SyRS → SRS → 설계 → 코드 → 테스트 간 연결성 검증 |
| 8 | L3 | STP/STD | Software Test Plan/Description | 테스트 계획/기술서 | 요구사항(SRS)이 제대로 구현되었는지 확인하기 위한 검증 문서 |
| 9 | L2 | SCMP | Software Configuration Mgmt Plan | 형상 관리 계획서 | 위 문서들의 버전 관리 및 변경 통제 절차 (L2 필수) |
문서 간 관계와 명칭의 '변종'이 생기는 이유
- URS vs SRS: * URS는 "사용자가 무엇을 원하는가?"(What they need)에 집중하며 보통 발주처가 작성하거나 분석 단계 초기에 작성합니다.
SRS는 "개발자가 무엇을 만들 것인가?"(What we build)에 집중하며, CMMI 심사 시 개발팀의 산출물로 가장 먼저 확인하는 문서입니다. - SyRS와 SyDS의 등장 배경:
- 단순 웹 서비스 개발이 아니라, 하드웨어 장비와 소프트웨어가 결합된 임베디드나 대규모 시스템 프로젝트에서는 '시스템(System)' 레벨의 정의가 먼저 필요합니다. 그래서 SyRS(시스템 요구사항)와 SyDS(시스템 설계) 단계가 추가됩니다.
- CMMI에서의 의미 (RTM의 중요성):
- CMMI 레벨 2와 3에서 가장 중요하게 보는 것은 RTM(요구사항 추적표)입니다.
- "URS에 있던 고객의 한 마디가 SRS의 어떤 항목이 되었고, 그것이 SDD의 어느 모듈로 설계되어 결국 어떤 테스트 케이스(STD)로 검증되었는가?"를 증명해야 합니다.
- 언급하신 SRS, SyRS 등의 문서는 이 추적성 체인을 구성하는 각각의 '고리' 역할을 합니다.
정리하자면, 규모가 큰 프로젝트일수록 URS → SyRS → SRS 순으로 문서가 세분화되며, CMMI 인증을 위해서는 이들 사이의 연결 고리를 문서화하는 것이 핵심입니다. 편의상 작은 프로젝트에서는 SyRS를 SRS에 통합하여 운영하기도 합니다.
함께 보기
https://ko.wikipedia.org/wiki/소프트웨어_공학
https://ko.wikipedia.org/wiki/시스템_공학
Use Case Diagram
https://brunch.co.kr/@acc9b16b9f0f430/126
TDD, Test Driven Development
https://namu.wiki/w/테스트%20주도%20개발
SDD, Spec Driven Development
https://yozm.wishket.com/magazine/detail/3477/
https://news.hada.io/topic?id=23776
...