출처: https://m.blog.naver.com/bycho211/221789956847
* 국내 소프트웨어 품질 프로세스 SP 품질인증 모델
- 소프트웨어 개발 프로세스 역량 수준을 평가, 인증하는 제도.
- 개선을 하기 위한 모델이 아닌, 평가를 하기 위한 모델
※ 평가를 하기 위한 모델인 SP 와는 달리, CMMI, SPICE 개선점을 찾기 위한 모델이다.
- 소프트웨어 산업진흥법에 근거, 국내 소프트웨어 기업의 수행 능력을 강화하고, 소프트웨어 사업의 부실 방지를 목적으로 한다.
- 기업의 소프트웨어 개발 단계별 작업절차 및 산출물 관리 역량 등을 분석한다.
* 프로세스 (Process) 란?
|
출처
|
정의
|
|
IEEE-STD-610
|
주어진 목적을 달성하기 위한 순서적인 절차
|
|
Olsen at el (1989)
|
특정한 목표나 목적을 달성하기 위한 활동, 작업 및 절차들의 집합
|
|
SEI CMMI
|
제품의 생산 및 진화에 사용되는 활동, 방법 및 실무 활동 들의 집합 인력, 절차, 방법, 장치 및 도구들이 원하는 산출물을 생산할 수 있도록 통합하는 수단
|
* 다른 관점의 프로세스 유형
1) 바깥쪽에서부터 안쪽으로 (Effect from outsize to inside) 조직, 회사 => 제품
- 표준 프로세스를 기반으로 프로젝트가 수행되고 있으면, 그 프로젝트에서 개발되는 제품은 품질을 보증한다. e.g) ISO/TS 16949, CMMI, SPICE, SP
2) 안쪽에서부터 바깥쪽으로 (Acting from inside to outside) 제품 => 조직, 회사
- 제품이 Acceptable한 수준의 품질을 증명하면 그 제품을 수행한 프로젝트와 조직 차원에서 품질 역량이 있다는 것으로 간주 e.g) Safety 관련 프로세스들 (ISO 26262 등등)
* 프로세스 개선 모델과 프로세스 평가 모델
1) 프로세스 개선 모델 (ex. CMMI, SPICE, ...)
- 가장 좋은 practice를 기준으로, 현재 조직에서 수행하는 프로세스에 대해 더 좋은 품질을 갖기 위해 어떤 개선점들이 있는지 도출하는 것이 목적인 모델이다.
- 프로세스에서 제시하는 기준은, 조직의 프로세스 품질 개선 요소를 찾아내는 기준에 불과하다.
- CMMI Level 3 인증을 확보했다고 해서, Level 3를 완벽하게 수행하고 있다고 CMMI Institute가 보증하지는 않는다. (미흡한 부분을 찾아낸 선임심사원이, 이 부분은 크리티컬하지 않고 개선이 가능하다고 판단하면 Level 3 인증을 할 수 있다. 다시 말해, 평가 자체가 목적이 아니므로 크리티컬하지 않은 부분에 대해서는 어느 정도 재량에 따라 인증을 하게 되고, 그 책임은 심사를 수행한 선임심사원이 지게 된다.)
2) 프로세스 평가 모델 (ex. SP, ...)
- 모델에서 제시하는 기준은 해당 조직이 해당 등급에서 요구하는 기준을 반드시 만족해야하는 의무사항이다.
- 인증기관은 평가 모델에 의해 인증을 획득한 조직이, 해당 등급에서 요구하는 활동을 만족스럽게 수행하고 있다는 것을 보증한다.
* SP 품질인증 히스토리
* SP 품질인증의 필요성
1) 비즈니스 환경의 변화
- 소프트웨어 기술 및 환경의 급격한 변화
- 소프트웨어 규모 및 복잡성 증가
- 소프트웨어 및 정보시스템의 품질 문제 유발
- 정보시스템의 품질문제는 현대사회의 전반적 문제를 야기하는 중요한 요인
(정보화 시대에 들어서면서, 많은 수의 국가 정보화 사업들이 생기게 되었다. 하지만 위와 같은 문제점들이 체계적으로 관리되지 못하고 있는 상황이었다. 하지만 정보화 시스템의 보완 및 유지보수 개발 업체 선정 기준에 혼동이 있었고, 명확한 업체 선정 기준이 필요하게 되었다.)
ref. 이러한 배경에서, SP 품질인증은 자연스레 공공IT 분야에 적합하도록 만들어졌다. 하지만 이후 등장한 새로운 분야인 '융합'과는 맞지 않는 부분이 많았는데, 법령의 개선이 발빠르지 못해 주먹구구식으로 이루어지는 경우가 많았다.
2) 소프트웨어 프로세스 품질 중요성 대두
- 소프트웨어 제품에 대한 품질에 치우친 제고(GS 인증, BMT 사업평가)
- 소프트웨어 프로세스의 품질을 보증하고 개선하는 제도 부재
3) 국내 기업의 어려움
- 국내 대부분의 기업들이 도입하는 정보시스템 및 소프트웨어에 대해서 객관적인 평가 없이 제안서 또는 레퍼런스 보유 여부로 사업자를 선정하는 상황이었다.
4) 외국 품질 프로세스 인증 의존
- 당시 국내 CMMI가 한창 확대되고 있었다. 하지만, CMMI 인증에는 기업들의 비용 부담이 컸고, 국내 중소 기업은 이를 인증받기가 쉽지 않은 일이었다. (도입 기간 1~2년, 컨설팅 비용 1~2억, 인증 비용 2~3천, ...)
=> 국내 정보화 사업의 사업자 선정 기준이 될 수 있고, 기업은 무담 없이 프로세스 품질 인증을 획득할 수 있는 제도 필요
* SP 품질인증의 구조와 구성
|
인증 등급
|
내용
|
|
1등급
|
프로젝트의 성공 여부와 관계없이 특정 프로젝트를 수행할 수 있는 수준이나,프로젝트 수행을 위한 기본적 인 활동들이 안정적으로 수행되지 못해 품질,비용,납기 측면에서 기대되는 목표를 충족시키지 못할 확률이 높은 상태로 프로젝트 수행을 위한 프로세스 역량 개선이 필요한 수준
|
|
2등급
|
개별 프로젝트를 수행하기 위해 필요한 프로젝트 차원의 프로세스가 수립되고,이를 기반으로 프로젝트를 통 제하여 성공적으로 프로젝트를 수행할 수 있는 역량 수준 (CMMI 2~3 사이의 수준)
|
|
3등급
|
조직의 프로세스 체계를 정의하고 정량적인 데이터 관리를 통해 조직 차원의 프로세스를 개선하고 발생되는 문제의 근본 원인을 해결함으로써 일관된 품질수준의 프로젝트 수행이 가능하며,지속적으로 프로세스를 개 선할 수 있는 역량 수준 (CMMI 4~5 사이의 수준)
|
※ CMMI에서는 개발 영역이 Level 3 에 있지만, SP에서는 2등급에 있다.
- 즉, CMMI에서는 개발보다는 관리가 우선되지만, SP에서는 개발을 보다 주요한 영역으로 보고 있음을 알 수 있다.
* SP 품질인증 심사의 특징
|
판정
|
세부 평가 항목 판정 기준
|
|
달성
|
• 점검항목의 판정결과가 모두 H인 경우
• 또는, 판정결과가 모두 H/M이며, M의 개수가 점검항목 전체갯수의 30%미만이면서 통합된 약점의 영향이 미미하다고 심사팀이 합의한 경우
|
|
대부분 달성
|
• 점검항목의 판정결과가 모두 H/M이며,M의 개수가 점검항목 전체갯수의 30% 미만이면서 통합된 약점의 영향이 중대하다고 심사팀이 합의한 경우
• 판정결과가 모두 H/M이며,M의 개수가 점검항목 전체 개수의 30%이상 50%이하이면서,통합된 약 점의 영향이 미미한 것으로 심사팀이 합의한 경우
|
|
일부 달성
|
• 점검항목의 판정 결과가 모두 H/M이며, M의 개수가 50%초과하는 경우
• 또는, 판정 결과가 H/M/L이며, L의 개수가 50%미만인 경우
|
|
미달성
|
• 달성 점검 항목의 판정결과가 H/M/L이며, L의 개수가 50%이상인 경우
|
- H/M/L/NA에 대한 평가 기준이 제시되지 않는다. 즉, 심사원의 경험과 지식 수준에 따라 평가 기준이 달라질 수 있는 상황이 발생한다.
|
판정
|
평가 항목 판정 기준
|
|
만족
|
• 모든 세부 평가 항목별 판정 결과가 달성 또는 대부분 달성인 경우
**단,모든 세부평가항목이 대부분 달성인 경운 불만족에 해당
|
|
불만족
|
• 만족의 경우 이외
|
|
판정
|
영역 판정 기준
|
|
인정
|
• 모든 평가항목별 판정결과가 만족인 경우
|
|
불인정
|
• 모든 평가항목별 판정결과가 만족이 아닌 경우이거나 평가항목별 판정결과 중 불만족이 있는 경우 (평가항목 중에 1개이상의 불만족이 있는 경우)
|
* SP 인증 심사의 특징
※ CMMI의 경우, 외부 심사원과 내부 심사원이 섞여서 심사한다.
* SP 품질인증 제도의 장점
1) 세계 유일의 국가 주도적 소프트웨어 프로세스 품질 인증 제도
- 중국, 베트남, 필리핀 등 신흥개발도상국에서는 국내의 국가주도적 소프트웨어 프로세스 품질 인증 제도에 대한 관심이 많은 상황이다.
- SP는 국내 품질인증이지만, 중국, 베트남에서는 SP 획득을 인정하는 경우가 있다.
=> SP 인증 업체가 해외 프로젝트를 수행할 때 국가가 소프트웨어 프로세스 품질 인증을 보증한다.
2) 국가 발주 정보화 사업에 가산점 인정
- SP 2단계 인증의 경우 품질점수 가산이 가능하다
- 국방 프로젝트의 경우 SP 2단계는 CMMI Level 3와 같은 역량으로 인정된다.
3) 국가 과제 신청 시 가산점 및 심사비용 지원
- 소프트웨어 공학 현장적용 사업 등 국가 과제 신청 시 SP 품질인증 심사를 희망하는 경우 가산점 및 심사비용이 지원된다. (불합격 시 일부는 회수된다.)
* SP 품질인증 제도의 개선 요소
1) 2020년 현재까지도 3등급을 획득한기업이 없다.
2) 대기업/중견기업 대비 중소기업의 인증 획득률이 낮다.
- 대기업 인증 성공 기업의 점수와 중소기업 미인증 기업 간의 점수 차이는 매우 크며, 특히 지원 평가 영역(품질보증, 형상관리, 측정 및 분석)에서 중소기업이 대기업 수준을 따라가기 어려움을 보여준다.
3) 융합소프트웨어 기업 적용에 한계가 있다.
- 국내 프로세스 인증 기업 중 임베디드 기업의 경우 SP보다 CMMI를 더 많이 획득한다. 그 이유는, 임베디드 업체는 주로 수출을 하므로 국내 인증은 SP를 획득할 이유가 없다. SP 인증을 획득한 4개의 임베디드 업체의 경우, 국내 판매보다는 정부지원사업을 받기 위해서 한 경우라고 볼 수 있다.
- 융합분야 기업이 SP 인증 획득 실패가 상대적으로 높음을 알 수 있다.
- 그 이유로는, SP 평가 항목이 공공정보화 SI 기반의 평가 항목이라는 점, 그리고 융합분야 경험을 보유한 심사원이 부족하다는 점을 들 수 있다.
- 2014년, 2015년에 융합분야 심사원들을 충원하여 이를 보강하였지만, 근본적인 해결책으로는 볼 수 없다. 보다 근본적인 SP 세부평가항목에 대한 융합분야 적용 보완이 필요하다.
- 임베디드 개발에서는 시스템 및 하그웨어와 소프트웨어간 인터페이스가 중요하다. 하지만, SP 인증 모델에서는 이 부분을 커버하기에 평가항목 및 세부평가항목들이 부족하다.
4) 최신 소프트웨어 개발 환경 변화에 더딘 대응
- SP 품질인증 제도는 정부 주도적으로 법규화되어 있어, 새로운 개발 환경 변화를 위한 제도 변경이 너무 어렵고 법체도 변경에 오랜 기간이 걸린다.
- CMMI의 경우, CMMI Institute에서는 현재 Version Change를 위해서 선임심사원과 파트너사들을 대상으로 변경 모델에 대한 의견을 수렴하고 있다. (빅데이터를 이용한 비즈니스가 늘어가는 상황에 발 맞춰 'Data Management' / 소프트웨어를 서비스로 보는 관점에 맞춰 DevOps를 위한 조치로서 agile guidanc, 회사 부도시 회생을 위한 방법도 프로세스에 넣는 등 최신 경향을 바로 반영한다.)
※ DevOps (데브옵스)
- 기존에는 소프트웨어를 제품으로 봤다. 즉, 개발 단계에서 제품이 완성되면, 이는 운영자에게 넘겨져 사용된다.
- 하지만, 이제는 소프트웨어를 서비스로 본다. 개발 단계 이후에도 서비스는 지속되어야 하며, 운영 중에도 질 좋은 서비스 제공을 위하여 수시로 개발된다.
5) 심사 대상 조직의 프로젝트 샘플링 수 결정 기준이 미흡하다.
- 심사 대상 조직에서 수행 중인 프로젝트 중 그 대상 조직에 가장 중요하다고 판단되는 프로젝트를 담당자 재량으로 결정한다. 조직의 규모, 투입된 인력 등에 기반한 샘플링 수에 대한 기준이 미흡하다.
6) 면접 심사 대상자에 대한 커버리지 기준이 미흡하다.
- 심사 대상 조직과 프로젝트 투입 인력을 고려해서 실제 프로세스가 내재화 되었는지를 평가할 수 있는 인력만큼을 면접 대상자로 충분히 선택되어야 하지만, 그에 대한 기준이 미흡하다.
* 해외 프로세스 품질 인증 모델과의 비교
- SP 품질인증이 국내 중소기업을 위한 인증모델이기 때문에, 국제적으로 통용되는 다른 프로세스 품질 인증과 비교했을 때 차이 (Gap) 을 가지고 있다.
- SP 품질인증이 해외 모델을 커버하지 못하고 부분집합의 형태로 존재한다. (장/단점이 존재)
- SPICE Coverage > CMMI Coverage > SP Coverage
'프로그램 개발(분석, 설계, 코딩, 배포) > 100. 기타' 카테고리의 다른 글
| 개발_ 주석 작성법 (0) | 2023.03.14 |
|---|---|
| 코드 기호 (0) | 2023.03.14 |
| java SE6(jdk1.6)을 상위버전으로 업그레이드 시 고민 사항 (0) | 2023.02.21 |
| JEUS_Unable to acquire the file lock (0) | 2023.02.03 |
| 리액트 기초 (0) | 2023.01.27 |
