[소프트웨어공학] 소프트웨어 품질 성숙도 모델. CMMI와 SPICE

 

1. 소프트웨어 프로세스 품질

소프트웨어 품질의 저하는 소프트웨어 개발 경험의 부족에서 오는 경우가 많다. 경험이 부족하여 제대로 된 소프트웨어 개발 프로세스가 없고 품질 향상을 위한 관리 활동도 찾아볼 수 없는 것이다. 세계의 대형 프로젝트의 단 1%만이 목표를 달성하고 있으며 개발 비용이 수백만 원 이상 초과되는 것은 물론이고 납기의 지연은 몇 년씩 연기되고 수십억 원의 개발비용이 투입된 프로젝트들이 실패로 끝나 무용지물이 되고 말았다.

소프트웨어 개발은 인력, 기술, 절차, 도구가 어우러져 통합된 프로세스, 즉 개발을 위한 작업이 질서 있고 경험이 잘 반영되어 있어야 소프트웨어의 품질을 높일 수 있다. 소프트웨어 시스템의 품질은 그것을 개발하는데 사용되는 프로세스의 품질에 좌우되는 것이다.

엔지니어링 프로세스가 경험에 따라 어떤 차이가 있는지 연구하고 모델을 제시하는 여러 가지 노력이 있었다. 그 중에서 특히 많이 알려진 것은 미 국방성의 CMM과 ISO의 SPICE이다. 또한 소프트웨어 개발 모델에 한정된 영역을 가지는 CMM과 달리 시스템과 소프트웨어 영역을 하나의 프로세스 개선 툴로 통합시킨 CMMI도 각광받고 있다.

 

 

2. CMMi

CMMI(Capability Maturity Model Integration)는 조직의 프로세스 개선을 통한 소프트웨어 개발 과정에서의 비용, 품질, 일정 등 모든 것을 충족시키며 특정 성숙도 레벨로 진입하기 위한 최소한의 기준 제시와 반드시 수행해야 할 활동들의 집합으로 프로세스 프레임워크의 성숙도 향상을 위한 모델로 소프트웨어 품질 보증 기준으로 널리 사용되고 있는 CMM의 후속 모델이다.

미국 국방부의 지원 아래 산업계, 카네기멜론대학 소프트웨어 공학연구소가 공동으로 CMM과 시스템 엔지니어링, CMM 등의 요소를 통합해 완성했다. 소프트웨어 개발 모델에 한정된 영역을 가지는 CMM과 달리 CMMI는 시스템과 소프트웨어 영역을 하나의 프로세스 개선 툴로 통합시켜 기업의 프로세스 개선 활동에 대한 광범위한 적용성을 제공한다.

CMMI 모델의 각 프로세스 영역의 특정 목표와 공통 목표 달성 정도를 측정함으로써 프로세스 개선 수준을 나타낸다. CMMI는 조직의 SW 개발뿐만 아니라 시스템설계, 하드웨어, 운영 등 시스템 통합 사업 전반에 대한 프로세스를 평가하고 정의하는 방법인 SCAMPI(Standard CMMI Appraisal Method for Process Improvement)를 제공한다. 특히 제품 또는 서비스의 개발, 획득, 유지보수하기 위한 조직의 공정 및 관리 능력을 향상하기 위한 가이드를 제공과 이를 통해 프로세스 개선 시 필요한 목표와 체계의 제공이 가능하다. 5단계로 구성되는 CMMI의 성숙도 레벨은 평가 조직의 프로세스를 개선 및 평가하기 위해 실행해야 할 실행지침을 포함한다.

 

 

2.1 프로세스 영역의 분류

CMMI의 프로세스 영역은 프로세스 관리, 프로젝트 관리, 공학, 지원의 4가지로 분류된다.

 

ㅁ 프로세스 관리

프로세스 관리 프로세스 영역은 프로세스를 정의하고 계획하고 전개하고, 적용하고, 감시하고, 조정하고, 평가하고 측정하고 개선하기 위한 프로젝트 간의 활동을 포함한다. CMMI의 프로세스 관리 프로세스 영역은 조직 프로세스 중점, 조직 프로세스 정의, 조직 훈련, 조직 프로세스 성과, 조직 혁신 및 이행의 5개의 프로세스 영역으로 구분된다.

 

ㅁ 프로젝트 관리

프로젝트 관리 프로세스 영역은 프로젝트를 계획하고 감시하고 통제하는 것과 관련된 프로젝트 관리 활동들을 다룬다. CMMI의 프로젝트 관리 프로세스 영역은 프로젝트 계획, 프로젝트 감시 및 통제, 공급자 계약 관리, 통합 프로젝트 관리, 위험관리, 통합팀, 정량적 프로젝트 관리의 영역으로 구분된다.

 

ㅁ 엔지니어링

엔지니어링 프로세스 영역은 개발과 엔지니어링 규율 간의 공유되는 유지보수 활동을 다룬다. 엔지니어링 프로세스 영역은 소프트웨어 공학과 시스템 공학을 하나 제품 개발 프로세스로 통합하고, 제품 기반 프로세스 개선 전략을 지원한다. CMMI의 엔지니어링 프로세스 영역은 요구사항 개발, 요구사항 관리, 기술 솔루션, 제품 통합, 검증, 확인의 영역으로 구분된다.

 

ㅁ 지원

제품 개발 및 유지보수를 지원하는 활동을 다룬다. 다른 프로세스들이 제대로 수행될 수 있도록 하는 프로세스들이다. 일반적으로 지원 프로세스 영역은 프로젝트를 목표로 하며, 조직에 대해 좀 더 일반적인 프로세스들이다. CMMI의 지원 프로세스 영역은 형상관리, 프로세스 및 제품 품질보증, 측정 및 분석, 통합을 위한 조직 환경, 결정 분석 및 해결, 원인분석 및 해결의 영역으로 구분된다.

 

 

2.2 소프트웨어 프로세스 성숙도 레벨 5단계

CMMI의 조직 개발 프로세스 성숙도는 레벨 1에서 레벨 5까지 나뉜다. 레벨1은 매우 미숙하고 혼돈된 프로세스이며, 레벨 5는 최적화된 가장 성숙한 최고 수준의 프로세스이다.

 

ㅁ 레벨 1 - Initial

개인의 역량에 따라 프로젝트의 성공과 실패가 좌우된다. 소프트웨어 개발 프로세스는 거의 없는 상태를 의미한다. 표준화된 프로세스 없이 프로젝트 수행 결과 예측이 곤란한 조직이며 적용 프로세스가 없다.

 

ㅁ 레벨 2 - Managed

프로세스 하에서 프로젝트가 통제되는 수준으로 조직은 프로세스에 대한 어느 정도의 훈련이 되었다고 볼 수는 있지만, 일정이나 비용과 같은 관리 프로세스 중심이다. 기존 유사 성공사례를 응용하여 반복적으로 사용한다. 기본적인 프로세스 구축에 의해 프로젝트가 관리되고 있는 조직이며 요구사항을 관리하고 프로젝트를 계획, 감시 및 제어, 공급자 계약 관리, 측정과 분석, 프로세스와 제품 품질 보증, 형상관리의 적용 프로세스가 존재한다.

 

ㅁ 레벨 3 - Defined

레벨 2에서는 프로젝트를 위한 프로세스가 존재한다면 레벨 3에서는 조직을 위한 표준 프로세스가 존재한다. 모든 프로젝트는 조직의 프로세스를 가져다 상황에 맞게 조정하여 승인받아 사용한다. 세부 표준 프로세스가 있어 프로젝트가 통제되는 조직이며 요구사항 개발, 기술적 해결, 제품 통합, 검증 가능, 조직 프로세스에 중점, 조직 프로세스 정의, 조직 훈련, 통합된 팀 구성, 통합된 프로젝트 관리, 통합된 공급자를 관리하는 적용 프로세스가 존재한다.

 

ㅁ 레벨 4 - Quantitatively Managed

소프트웨어 프로세스와 소프트웨어 품질에 대한 정량적인 측정이 가능해진다. 조직은 프로세스 데이터베이스를 구축하여 각 프로젝트에서 측정된 결과를 일괄적으로 수집하고 분석하여 품질평가를 위한 기준으로 삼는다. 프로젝트 활동이 정략적으로 관리, 통제되고 성과 예측이 가능한 조직이며 조직적 프로세스 성과, 정량적인 프로젝트를 관리하는 적용 프로세스가 존재한다.

 

ㅁ 레벨 5 - Optimizing

레벨5에서는 지속적인 개선에 치중한다. 조직적으로 최적화된 프로세스를 적용하여 다시 피드백을 받아 개선하는 상위 단계이다. 지속적인 개선활동이 정착화되고 최적의 관리로 프로젝트가 수행되는 조직이며 조직 혁신 및 이행, 분석과 해결의 적용 프로세스가 존재한다.

 

 

 

 

3. SPICE

엔지니어링 프로세스가 경험에 따라 어떤 차이가 있는지 연구하는 모델 중 CMMI와 함께 각광받고 있는 모델이 SPICE이다. SPICE는 소프트웨어 프로세스 평가를 위한 국제 표준을 제정하는 프로젝트이다. 미 국방성의 CMM과 유사한 프로세스 평가를 위한 모델을 제시하며 심사 과정도 제안하고 있다. 1995년에 ISO/IEC 15504라는 규격으로 완성되었으며 우리나라를 포함한 20여 개국이 표준화 제정에 계속 참여하고 있다. 또한 SPICE를 기준으로 한 심사와 평가가 양성된 심사원에 의하여 이루어지고 있다.

SPICE는 CMM과 같이 프로세스 심사를 위한 참조 모형을 제공한다. 즉 개발 성숙도에 따라 차별화된 수준을 정의하고 각 수준의 특징을 밝혀 심사할 때 어떤 기관이 어떤 수준에 있는지 판단할 수 있도록 예시하고 있다.

 

 

3.1 프로세스 영역의 분류

SPICE의 프로세스 영역은 고객 공급자, 엔지니어링, 지원, 관리, 조직 프로세스로 분류된다.

 

ㅁ 고객 공급자 프로세스

소프트웨어를 개발하여 고객에게 제공하고 소프트웨어를 정확하게 운용하고 사용하도록 지원하기 위한 프로세스. 예를 들면 발주, 공급자 선정, 고객 인수, 요구사항 도출, 공급, 운영 등이 여기에 속한다.

 

ㅁ 엔지니어링 프로세스

시스템과 소프트웨어 제품을 개발하는 모든 프로세스, 즉 요구분석, 설계 및 실험, 구축, 통합 등의 프로세스가 여기에 속한다.

 

ㅁ 지원 프로세스

문서화, 형상관리, 품질 보증, 검증, 확인, 검토 등 개발 활동을 지원하는 프로세스이다.

 

ㅁ 관리 프로세스

일반적인 소프트웨어 프로젝트에서 일어나는 관리 활동, 예를 들면 프로젝트 관리, 품질 관리, 위험 관리 등이 이 범주에 속한다.

 

ㅁ 조직 프로세스

조직의 업무 목적을 수립하고 좆기이 업무 목적을 달성하기 위하여 도움을 주는 프로세스, 예를 들면 프로세스의 정의, 심사, 개선, 인적자원 관리, 기반 구조, 측정, 재사용에 관한 사항이 여기에 속한다.

 

 

3.2 소프트웨어 프로세스 성숙도 레벨 6단계

SPICE의 조직 개발 프로세스 성숙도는 레벨 0에서 레벨 5까지 6단계로 나뉜다.

 

ㅁ 레벨 0 - Incomplete

특정한 프로세스의 작업이 목표 달성에 실패하는 경우가 많다. 쉽게 생각할 수 있는 프로세스의 작업 산출물이나 결과가 존재하지 않는 수준이다.

 

ㅁ 레벨 1 - Performed

프로세스의 작업 목표는 어느 정도 달성한다. 그러나 프로세스를 성공적으로 완수하기 위하여 철저하게 계획하거나 추적되지 않을 수도 있다. 조직 내의 구성원은 더 철저한 관리를 수행하여야 한다는 것을 인지하고 있으며 더 강력한 노력이 필요하다는 점에 대하여 동의한다. 구별된 작업 산출물이 존재하고 이들을 근거로 목표 달성 여부가 결정된다.

 

ㅁ 레벨 2 - Managed

프로세스가 정해진 절차에 따라 이루어져 산출물을 내며 모든 작업이 계획되고 추적된다. 산출물은 명시된 표준과 요구사항에 부합한다. 레벨 1과의 차이점은 정해진 시간과 자원 한도 안에서 프로세스를 수행하며 정해진 품질 요구사항을 만족하는 산출물을 낸다는 것이다.

 

ㅁ 레벨 3 - Established

소프트웨어 엔지니어링 원리에 근거하여 프로세스를 정의하고 이를 이용하여 프로세스를 수행하고 관리한다. 정의된 프로세스가 표준화되어 있고 문서화되어 있다. 프로세스를 수행할 때는 표준 프로세스를 알맞게 조정하여 승인받은 후 사용한다. 레벨 2와의 차이는 프로세스에 정의된 성과를 달성할 수 있도록 표준으로 정의된 프로세스를 사용한다는 점이다.

 

ㅁ 레벨 4 - Predictatble

프로세스의 목표를 달성하기 위하여 정해진 프로세스를 수행하되 일정한 통제 범위 내에서 일관성 있게 수행한다. 프로세스를 수행한 후 자세한 측정값을 수집하고 분석한다. 이를 이용하여 프로세스 능력을 정량적으로 이해할 수 있고 수행을 예측하고 정량적으로 관리할 수 있는 성숙된 능력을 발휘할 수 있다. 따라서 작업 후 산출물의 품질도 정량적으로 알 수 있다. 레벨 3과의 차이점은 정해진 성과를 달성하기 위하여 표준 프로세스를 수행하며 그 결과는 일정한 한도 내에서 통제된다는 점이다.

 

ㅁ 레벨 5 - Optimizing

프로세스가 최적화되어 있어 현재 프로젝트만이 아니라 미래에 수행될 프로세스에 대하여도 목표를 잘 만족시킬 수 있다. 프로젝트에서 수립된 목표에 따라 프로세스를 수행할 때 달성할 정량적인 효율 목표를 설정한다. 정량적인 피드백을 얻게 되면 목표에 대하여 지속적으로 프로세스에 대한 모니터링이 가능하고 결과를 분석하여 지속적인 개선을 할 수 있게 된다. 프로세스를 최적화하기 위하여 혁신적인 아이디어와 기술은 시범적으로 적용하여 도입하고 비효율적인 프로세스는 과감히 바꾸는 성숙도를 보여야 한다. 레벨 4 와의 차이점은 현재와 미래의 프로젝트를 성공적으로 완성시키기 위하여 정의된 표준 프로세스가 계속적으로 향상되기 위하여 역동적인 변화 및 시도가 있다는 점이다.

 

 

 

4. CMMi vs SPICE

SPICE와 CMM의 중요한 차이점은 성숙도 레벨과 심사영역의 구분이다. CMM은 레벨 1부터 5까지 5개의 성숙도 수준으로 정의하고 있으나 SPICE는 레벨 0부터 5까지 6개의 수준으로 나누고 있다. 또한 CMM은 어떤 기관의 프로세스 능력을 여러 분야에 걸쳐 평가하여 하나의 레벨로 평가하는 일차원적인 구조를 가지고 있으나 SPICE는 각 프로세스 영역마다 능력에 대한 평가를 별도로 할 수 있어 2차원적인 구조를 가지고 있다.

 

 


[소프트웨어공학] 애자일 소프트웨어 개발 방법론: Crystal 완벽 정리

 

[소프트웨어공학] 애자일 소프트웨어 개발 방법론: Crystal 완벽 정리

시리즈 글보기 [소프트웨어공학] 애자일 소프트웨어 개발 방법론: Scrum 완벽 정리 B. Boehm, “A survey of agile development methodologies.” Laurie Williams, 2007. 보헴의 A Survey of Agile Development M..

mk28.tistory.com

 

 

[소프트웨어공학] 소프트웨어 개발생명주기(SDLC) 모델 핵심 정리

 

[소프트웨어공학]소프트웨어 개발생명주기(SDLC) 모델 핵심 정리

1) 폭포수 모형(Waterfall Model) 특징 1970년대 항공 소프트웨어 개발 경험으로 습득 계획 -> 요구분석 -> 설계 -> 구현 -> 테스트 -> 인수 설치 각 단계가 순차적으로 진행되며 다음 단계는 이전 단계가

mk28.tistory.com

 

 

참고문헌

[Wikipedia]능력 성숙도 모형 결합 http://ko.wikipedia.org/wiki/CMMI

[Wikipedia]ISO/IEC15504 - http://ko.wikipedia.org/wiki/ISO/IEC15504

[네이버 지식백과] CMMI [Capability Maturity Model Integration]

http://terms.naver.com/entry.nhn?docId=858068&cid=391&categoryId=391

소프트웨어 공학 | 최은만 저 |정익사

 

 

 

 

 

 

궁금한 사항은 댓글로 남겨주세요💃💨💫
좋아요와 구독(로그인X)은 힘이 됩니다 🙈🙉

 

 

 

 

반응형
그리드형

댓글

❤️김세인트가 사랑으로 키웁니다❤️