소프트웨어 프로세스와 품질
ISO 12207 표준
국제표준 ISO/IEC 12207 소프트웨어 생명주기 프로세스 (프로세스 중심의 각 활동 및 역할에 대해 기술한다)
소프트웨어 개발 프로세스를 정의하고 향상시키기 위한 프로세스. 다양한 형태의 소프트웨어 개발 및 관리에 적용될 수 있는 과정(process), 활동(activity) 및 단위업무(task)를 정의한다
소프트웨어 개발 프로세스를 위한 프레임워크이며, 기본공정, 지원공정, 조직공정 등으로 이루어진다
주요 프로세스별 활동
기본 생명주기 프로세스 (기본공정)
1. 획득 (aquisition)
시스템, 소프트웨어 제품 또는 소프트웨어 서비스를 획득하는 데 획득자 또는 획득조직이 수행할 활동 정의
2. 공급 (supply)
시스템, 소프트웨어 제품 또는 소프트웨어 서비스를 획득하는 데 공급자 또는 공급조직이 수행할 활동 정의
3. 개발 (development)
시스템, 소프트웨어 제품을 정의하고 개발하는 개발자 또는 개발조직이 수행할 활동을 정의
4. 운영 (operation)
시스템의 운영 서비스를 제공하는 운영자 또는 운영조직이 수행할 활동을 정의
5. 유지 보수 (maintenance)
제품의 유지 보수 서비스를 제공하는 유지보수자 또는 유지보수조직이 수행할 활동을 정의
지원 생명주기 프로세스 (지원공정)
1. 문서화 (documentation)
정보의 기록을 위한 활동을 정의
2. 품질보증 (quality assurance)
소프트웨어 제품 및 프로세스가 명시된 요구사항에 적합하여 이미 수립된 계획에 따르고 있음을 객관적으로 보증하기 위한 활동을 정의
3. 형상관리 (configuration management)
구성관리 활동을 정의
4. 검증 (verification)
소프트웨어 프로젝트에 따라 소프트웨어 제품을 검증하기 위한 활동을 정의
5. 확인 (validation)
소프트웨어 프로잭트의 소프트웨어 제품을 확인하기 위한 활동을 정의
6. 문제해결 (problem resolution)
다른 프로세스 활동 중 발견한 부적합 사항을 포함한 문제점을 분석, 제거하기 위한 프로세스를 정의
7. 합동검토 (joint review)
활동의 상태 및 제품을 평가하기 위한 활동을 정의
8. 감사 (audit)
요구사항, 계획 및 계약에 대해 적합성을 결정하기 위한 활동을 정의
조직 생명주기 프로세스 (조직공정)
1. 기반구조(infrastructure)
생명주기 프로세스의 기본구조를 확립하기 위한 기본활동을 정의
2. 관리 (management)
생명주기 프로세스 동안 프로젝트 관리를 포함한 기본적인 관리활동을 정의
3. 개선 (improvement)
조직 생명주기 프로세스의 확립, 측정, 통제, 개선을 위해 수행하는 기본활동을 정의
4. 훈련 (training)
적절하게 훈련된 요원을 제공하기 위한 활동을 정의
CMMI 모델 (Capability Maturity Model Integration)
조직의 개발 프로세스 역량 성숙도를 평가하기 위해 미국 카네기 멜론 대학의 소프트웨어 기술연구소 (SEI)가 제안한 통합 모델이다. 다양한 기업에 걸쳐 광범위하게 적용할 수 있도록 프로세스 개선을 위한 프레임워크를 제공한다
- 개발을 위한 CMMI
- 발주를 위한 CMMI
- 서비스를 위한 CMMI
어떤 모델이라도 CMMI 기술들은 조직의 업무 목적에 맞게 수정하여 사용할 필요가 있다.
CMMI 모델은 여러 CMM 모델들이 통합되어 만들어진다
- SW-CMM (소프트웨어 능력 성숙도 모델)
- SECM (시스템 엔지니어링 능력 모델)
- IPD-CMM (통합 제품 개발 능력 성숙도 모델)
- People CMM (인력의 개발과 관리)
- SA-CAM (소프트웨어 획득)
- SECAM (시스템 엔지니어링 능력 심사 모델)
CMMI는 여러 CMM모델의 가장 효과적인 특성 및 공통 요소를 포함하면서, 이들이 지원하는 분야에서 공통적으로 사용할 수 있는 영어 및 교육과 통합된 평가방법을 제공한다
CMMI는 시스템 공학과 소프트웨어 공학의 기능적 통합에 중점을 두고 있으며, 통합된 제품(product)을 개발하기 위한 기반을 제공하고 있다
다른 분야로의 확장이 가능한 구조로 제품을 효과적으로 개발, 구매, 유지보수하기 위한 기반을 제공한다
CMMI 모델의 구성과 성숙도 단계
CMMI 의 프로세스 영역
범주 | 프로세스 영역 |
프로세스 관리 | 조직의 프로세스 정의, 초점, 성과 조직의 훈련, 혁신과 배치 |
프로젝트 관리 | 프로젝트 계획수립, 모니터링과 통재 공급자와의 합의관리 통합된 프로젝트 관리, 팀 구성 위험관리 정량적인 프로젝트 관리 |
엔지니어링 | 요구사항 관리, 개발 기술적 해결책 제품통합 증명 검증 |
지원 | 형상관리 프로세스와 제품의 품질 경영 측정과 분석 의사결정, 임시분석과 해결책 통합을 위한 조직의 환경 |
CMMI의 성숙도별 키 프로세스 영역
성숙도 수준 | 초점 | 주요 프로세스 영역 |
수준 5 Optimizing |
지속적 프로세스 개선 | 조직 혁신 및 이행 (OID ; Organizational Innovation & Deployment) 분석과 해결 (CAR ; Casual Analysis & Resolution) |
수준 4 Quantitatively Managed |
정량적 관리 | 조직 프로세스 성능 (OPP ; Organizational Process Performance) 정량적인 프로젝트 관리 (QPM ; Quantitative Project Management) |
수준 3 Defined |
프로세스의 표준화 | 요구사항 개발 (RD ; Requirement Development) 기술적 해결 (TS ; Technical Solution) 제품통합 (PI ; Product Integration) 검증 (VER ; Verification) 확인 (VAL ; Validation) 조직 프로세스 중점 (OPF ; Organizational Process Focus) 조직 프로세스 정의 (OPD ; Organizational Process Definition) 조직 훈련 (OT ; Organizational Training) 통합된 프로젝트 관리 (IPM ; Integrated Project Management) 위험관리 (RSKM ; Risk Management) 의사결정 분석 및 결정 (DAR ; Decision Analysis and Resoultion) |
수준 2 Managed |
기본 프로젝트 관리 | 요구사항 관리 (REQM ; Requirements Management) 프로젝트 계획 (PP ; Project Planning) 프로젝트 감시 및 제어 (PMC ; Project Monitoring and Control) 공급자 합의관리 (SAM; Supplier Agreement Management) 측정과 분석 (MA ; Measurement and Analysis) 프로세스와 제품 품질보증 (PPQA ; Product & Process Quality Assurance) 형상관리 (CM ; Configuration Management) |
수준 1 Inital |
초기상태 | 초기상태 |
CMMI의 단계적 (staged) 모델
소프트웨어 CMM 모델에 적합하며 조직의 시스템 개발과 관리 프로세스가 평가되어 1부터 5까지의 성숙도 수준을 할당한다. 각 수준에서 달성해야 하는 목표를 기술하여 각 수준의 practice를 실현하고 모델의 낮은 수준에서 높은 수준으로 이동하여 달성된다
소프트웨어 CMM에 적합하고 조직을 위한 분명한 개선경로를 정의하는 것이 장점
낮은 수준의 관례를 도입하기 전에 높은 수준에서 목표와 관례를 도입하는 것이 더욱 적절할 수 있다
CMMI의 연속적 (continuous) 모델
더 세분화된 분류가 가능하며 24개의 프로세스 영역에 대해 0부터 5까지의 등급을 부여한다.
매우 조밀한 모델로, 관계를 개별적으로 또는 그룹으로 고려하여 각 관례의 이용을 평가한다. 성숙도 평가는 단일값이 아니고 각 프로세스나 프로세스 그룹에 대한 조직의 성숙도를 나타내는 값들의 집합이다.
조직이 자신의 필요와 요구사항에 따라 개선하기 위한 프로세스를 선택할 수 있다는 장점이 있다
CMMI 의 성숙도 단계
단계 | 정의 | 연속적 모델 | 단계적 모델 |
0 | 실행되지 않음 | Not Performed | |
1 | 예측, 통제되지 않음 | Performed | Initial |
2 | 프로젝트에 적합한 프로세스 적용 | Managed | Managed |
3 | 조직 차원의 표준 프로세스 존재 | Defined | Defined |
4 | 프로세스의 정량적 측정, 관리 | Quantitaively Managed | Quantitaively Managed |
5 | 지속적인 프로세스의 개선 | Optimizing | Optimizing |
CMMI의 프로세스 개선방식
구분 | 연속적 모델 | 단계적 모델 |
Process Area | Capabillity Level 로 그룹화 | Maturity Level로 그룹화 |
예제 모델 | SW-CMM | SW-CMM |
성숙도 단계 | 0 ~ 5 단계 | 1 ~ 5 단계 |
특징 | 조직을 불연속적인 수준에 따라 분류하지 않음 조직의 비즈니스 목적을 충족시키고 위험 요소를 완화시키는데 중요한 개선 사항의 순서를 정하여 적용 특정 프로세스 영역에 대한 조직 간의 비교가 가능 ISO/IEC 15504(SPICE)와 유사한 구조를 가지고 있어 이를 기반으로 프로세스 개선 모델과의 비교가 가능 |
기업들이 차례대로 상이한 단계에 초점을 맞출 것을 요구 널리 입증된 순서에 따른 체계적인 개선활동 제공, 가장 기초적인 관리절차로부터 상위수준으로 향상되기 위해 필요한 실무까지 수행되어야할 프로세스 영역들을 단계별로 제시 성숙도 수준을 이용한 조직 간의 비교가 가능 조직에 대한 평가 결과를 요약해 주며 조직 간 비교를 가능하게 하는 단일 등급체계를 제공 |
장단점 | 조직이 자신의 필요와 요구사항에 따라 개선하기 위한 프로세스를 선택할 수 있음 | 조직을 위한 분명한 개선경로 정의 낮은 수준의 practice를 도입하기 전에 높은 수준에서 목표와 practice를 도입하는 것이 더 적절할 수 있기 때문에 조직의 성숙도 평가 능력을 오해하게 만들 수 있다 |
SPICE 모델 (Software Proecss Improvement and Capability dEtermination)
소프트웨어 프로세스 평가를 위한 국제표준을 제정하는 프로젝트
미 국방성의 CMM과 유사한 프로세스 평가를 위한 모델을 제시하며 심사 과정도 제안한다
ISO 12207 소프트웨어 생명주기 프로세스를 참고로 하며, 1995년에 ISO/IEC 15504라는 규격을 완성하였으며, 대한민국을 포함한 20여 개국이 표준화 제정에 계속 참여하고 있다
SPICE는 다음 3가지 목적을 위하여 제정하였다
1. 개발기관이 프로세스 개선을 위하여 스스로 평가
2. 기관에서 정한 요구조건을 만족하는지 개발조직이 스스로 평가
3. 계약을 맺기 위하여 수탁기관의 프로세스를 평가
출현배경
1. CMM의 경우 조직을 평가하므로 제품의 품질과는 직접적인 연관이 없다
2. CMM의 경우 조직 전체에 대한 등급 판정은 비효율적, 비 현실적이다.
3. CMM의 경우 소규모 업체에서는 적용이 곤란하다
특징
1. 개발 성숙도에 따라 차별화된 수준을 정의하고 각 수준의 특징을 밝혀 심사할 때 어떤 기관이 어떤 수준에 있는지 판단 가능
2. 각 프로세스 영역마다 능력에 대한 평가가 가능해 이차원적 구조를 지닌다
3. 무능력한 상태로부터 최적화된 상태까지 6단계로 나누어 능력을 평가한다
4. 전 세계에 공통적으로 적용된다
프로세스 수행 능력 수준
수준 | 설명 |
수준 0 불완전 단계 (incomplete) |
프로세스가 구현되지 않았거나 프로세스가 그 목적을 달성하지 못한다 프로세스 결과물이 거의 없거나 쉽게 인식이 불가능한 상태이다 |
수준 1 수행 단계 (performed) |
프로세스의 목적이 전반적으로 이루어진 단계이다 프로세스가 정의된 산출물을 산출한다 수행되어야할 조치가 거의 없거나 쉽게 인식이 불가능한 상태이다 |
수준 2 관리 단계 (managed) |
정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도한다 프로세스의 계획 및 추적이 수행되는 단계이다 수준 1과의 차이점은 정의된 시간 제약과 자원의 요구하에서 품질 요구사항을 만족하는 결과물을 산출하는 프로세스를 수행한다는 것이다 |
수준 3 확립 단계 (established) |
소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행된다 프로세스 정의에 필요한 자원이 마련되어 있다 개별 프로세스의 구현은 프로세스 결과물의 성취를 목적으로 승인되고 개별 건에 맞춰 조정된 표준과 문서화된 프로세스를 사용한다 수준 2와의 차이점은 프로세스 결과물의 성취를 가능하게 하는 표준으로 정의된 프로세스의 사용 여부에 있다 |
수준 4 예측 단계 (predictable) |
프로세스가 목적달성을 위해 통제되고 양적인 측정을 통해서 일관되게 수행된다 세부적인 수행결과에 대한 측정값의 수집과 분석이 가능하다 프로세스 능력의 정량적 이해와 개선된 수행 예측 및 관리능력을 보유한 단계이다 품질에 대한 정량적 파악이 이루어진다 수준3과의 차이점은 프로세스 결과물의 성취를 위해 정의된 프로세스가 일정한 통제하에 일관되게 수행된다는 것이다 |
수준 5 최적화 단계 (optimizing) |
프로세스 수행을 최적화하고, 지속적으로 업무 목적을 만족시킨다 목표에 근거해 정량적 프로세스 목표에 관한 효과성과 효율성을 확립한다 정량적 피드백으로 목표에 대한 지속적 프로세스 감시가 가능하며, 결과분석을 통해 개선이 가능하다 창의적 아이디어와 기술의 시험적 적용, 정의된 목표의 부합을 위해 비효과적인 프로세스를 변경하는 등 프로세스의 최적화가 이루어진다 수준 4와의 차이점은 정의된 표준화된 프로세스의 동적인 변화와 현재 및 미래 목표에 효과적인 적응에 있다 |