전문가칼럼

소프트웨어 품질인증 왜 필요한가

페이지 정보

AB&I 작성일07-12-27 17:52

본문

소프트웨어가 고품질, 저비용, 적시성을 갖추고 개발된다면 경쟁력을 높일 수 있다. 최근 소프트웨어 품질에 대한 사회적인 관심이 증가하면서 품질 인증에 대한 관심도 함께 커지고 있다. 개발자 입장에서 볼 때 소프트웨어 품질이 좋다면 이를 적극 알리고자 할 것이며, 사용자 입장에서 보면 소프트웨어의 품질 수준을 미리 알 수 있으면 구매시 많은 도움이 된다. 그렇다면 공인기관 또는 자격을 갖춘 개인이 품질을 인증해 주면 도움이 되지 않을까? 소프트웨어 품질 인증은 이러한 요구에서 시작된다.

소프트웨어의 품질 인증은 크게 두 가지로 나눌 수 있다. 하나는 소프트웨어의 제품 품질을 평가하여 인증하는 것이고, 또 하나는 소프트웨어 개발 프로세스를 평가하여 인증하는 것이다. 한국정보통신기술협회(TTA) IT시험연구소에서 시행하는 소프트웨어 품질인증은 제품에 대한 인증에 해당된다. 그러나 소프트웨어는 매우 복잡한 과정을 거쳐 개발되므로 최종 제품에 대한 시험(testing)에만 의존하는 제품 인증보다는 프로세스에 초점을 맞추는 것이 바람직하다는 의견이 대두되면서 나온 것이 프로세스 품질 인증이다.

최근들어 기술이 급격히 발전되고 경쟁이 심화되면서 소프트웨어 개발자는 비용, 납기, 고객에 더욱 민감해지고 있다. 소프트웨어 개발 프로젝트가 성공적으로 수행되기 위해서는 사용자의 요구사항을 만족시키는 소프트웨어를 개발해야 함은 물론이고, 납기일에 맞추어(on time), 주어진 예산 한도 내(within budget)에서 개발돼야 한다. 오늘날 대부분의 소프트웨어 개발 조직은 이를 충족시키지 못하는 위기상황에 직면하고 있다.

스탠디시 그룹(Standish Group)에서 조사한 지난 1995년 통계에 따르면 2천5백억 달러가 매년 개발 프로젝트에 사용되지만, 그 중 31%(약 8백10억 달러)가 종료 이전에 취소되며, 남은 프로젝트 중 53%의 프로젝트는 189%(약 5백90억 달러)까지 비용이 초과 지출됐다고 한다. 이러한 경향은 최근까지 계속되고 있다.




<그림 1> CMM 능력 수준



<그림 2> SPICE 평가모형


프로세서 개선에 따른 효과

프로세스 접근방법은 와츠 험프리가 말한 ‘소프트웨어 시스템의 품질은 그 시스템을 개발하고 전개 시키는 프로세스의 품질에 의해 결정된다’는 전제에서 출발한다. 즉 모든 소프트웨어 개발 업무를 프로세스로 생각하고 이를 통제하고, 측정하고, 개선시킬 때 고품질 소프트웨어가 적기에 저비용으로 개발될 수 있다는 것이 프로세스 접근방법이다.

소프트웨어 개발에서의 프로세스는 개발 조직의 목표를 달성하기 위해 조직 내에서 사용되는 활동(activities), 방법(methods), 실무지침(practices) 등을 일컫는다. 프로세스의 능력(capability)은 해당 프로세스에 따라 작업을 수행할 때 기대되는 성과의 효과성이라고 정의할 수 있고, 프로세스 심사를 통해 능력을 판단할 수 있다. 능력 수준이 높다는 것은 프로세스가 그만큼 효과적이라는 의미가 된다. 이 때 프로세스 개선은 프로세스 능력 수준을 높이기 위해 수행되는 노력이라고 할 수 있다.

프로세스를 개선하면 과연 효과가 있을까? 1995년 SEI(Software Engineering Institute)의 조사 결과에 따르면 프로세스 개선을 위한 투자 대비 효과, 즉 사업가치는 약 5배에 이른다.

다음은 프로세스 개선에 따른 성공사례들을 보여주고 있다. 첫째, 모토롤라는 재작업 비용을 8분의 1로 줄일 수 있었다. 둘째, 보잉은 87%의 예측정확도 향상, 130%의 품질개선, 62%의 생산성 향상, 22%의 종업원 만족도 개선 등의 결과를 얻었다. 셋째, HP는 1천 라인 당 결함의 수를 0.4개에서 0.11개로 줄일 수 있었다. 다섯째, 레이션(Raytheon)은 개선비용 1달러를 들여 재작업에 따른 비용을 7.8달러를 줄일 수 있었다. 여섯째, 텍사스 인스트루먼트는 결함 정정 시간을 8시간에서 11분으로 줄일 수 있었다.


CMM과 SPICE의 차이점

그렇다면 CMM과 SPICE는 과연 무엇이 다른가? CMM(Capability Maturity Model)과 SPICE(Software Process Improvement and Capability dEtermination)는 소프트웨어 업체의 프로세스 능력을 심사하고 개선할 수 있는 방법을 제공하는 대표적인 모형이다. CMM은 1980년대 후반 미국 국방성(DoD)의 의뢰를 받아 카네기멜론대학의 SEI(Software Engineering Institute)에서 개발됐다. CMM에서는 소프트웨어 프로세스 능력을 5개의 수준으로 평가한다. <그림 1>은 각 수준의 의미를 나타낸다.

CMM은 각 수준 별로 핵심적으로 수행돼야 하는 프로세스들을 정의하고 있다. 업체에서 그 프로세스들을 모두 수행하고 있으면 해당 수준을 달성했다고 판단한다. 또 프로세스 능력을 향상시킬 수 있는 경로를 명확히 제시한다.

이에 비해 SPICE는 CMM의 영향을 받아 제정된 소프트웨어 프로세스 심사에 관한 국제표준이다. SPICE는 전세계적인 시범적용으로 데이터를 분석해 모형의 신뢰성을 높이는 방법을 채택하고 있다. SPICE는 소프트웨어 생명주기 프로세스 표준에 따라 정의된 각각의 프로세스를 0에서 6까지의 수준으로 평가한다. <그림 2>와 같이 각 수준의 의미는 CMM과 유사하다. 따라서 SPICE를 이용하여 프로세스를 개선하기 위해서는 업체의 특성에 맞는 핵심 프로세스들을 먼저 선택하고, 프로세스 별 목표 수준을 정한 후 개선이 이루어진다.

국내에서는 SI업체를 중심으로 지난 1990년대 후반부터 CMM 및 SPICE를 도입해 적용해 왔다. CMM의 경우 심사를 진행할 수 있는 선임심사원의 자격요건이 매우 까다로워 최근까지 내국인 선임심사원이 전무했다(최근 선임심사원이 LG CNS에서 1명 배출됨).

CMM 심사를 위해서는 많은 비용을 들여 외국에서 선임심사원을 초빙해야 했다. 국내에서CMM 심사를 받은 업체는 그리 많지 않지만 CMM 3수준에 도달한 업체들도 몇몇 나타나고 있다. 정부에서는 국내 CMM 선임심사원의 필요성을 인식해 한국소프트웨어진흥원의 소프트웨어공학센터(KSI)를 통해 2002년부터 매년 15명씩 선임심사원을 양성할 계획이다.

SPICE의 경우 한국SPICE위원회(KSPICE) 주도로 지난 1998년부터 현재까지 약 4백여명에 이르는 심사원을 양성해 왔다. 한국소프트웨어심사인협회가 조직돼 운영되고 있으며, 풍부한 SPICE 심사원들을 활용하여 많은 기업에서 SPICE 심사와 개선이 활발하게 이루어지고 있다. 현재까지 수십 건의 심사가 이루어졌고 그 결과를 국제표준에 반영하고 있다. 그렇다면 우리나라 기업의 프로세스 능력수준은 대체로 어느 정도일까?




국내 프로세서 인증 환경

올해 한국소프트웨어진흥원 주관으로 실시한 국내 정보기술 프로세스 능력 수준 조사 결과에 따르면 조사에 참여한 45개 기업 중 대부분이 CMM 능력 수준 1로 나타났다. 그만큼 국내 소프트웨어 산업은 고질적인 프로세스 관리 능력의 부재와 품질 및 개발생산성 저하로 인해 수익성이 악화되고, 프로젝트가 부실화되며, 기술적 발전이 저해되는 악순환이 반복되고 있음을 보여준다. 또한 최저가 낙찰제, 덤핑 입찰, 제안서 무보장 등 정책 요인들도 소프트웨어 산업의 구조를 더욱 악화시켜 왔다.

최근 업체들이 프로세스 인증에 열을 올리는 이유는 프로세스 능력 향상을 통해 경쟁력을 제고하겠다는 것이 가장 큰 요인이다. 프로세스 인증 결과를 활용하면 계약시 유리한 위치를 선점할 수 있으며, 인증 결과 자체가 업체를 홍보하는 수단이 되기도 한다. 최근 정통부가 개정하고 있는 소프트웨어사업자 평가제도에서도 업체들의 프로세스 능력을 기반으로 하고 있어 업체들은 품질 인증에 대한 관심은 매우 높다고 할 수 있다.

그렇다면 CMM이나 SPICE 중 어느 모형이 적당할까? 그 선택은 고객의 요구사항, 비용 등을 고려해야 한다. 미 국방성이나 연방정부에서는 CMM 심사 결과를 요구하는 경우가 많아 미국에 진출하기 위해서는 CMM심사가 필수적이다. 그러나 회사 내부의 프로세스 개선이 목적이라면 어느 모형이라도 사용할 수 있다.

CMMI(CMM Integration)가 지난 2001년 발표되면서 SPICE와 호환가능하기 때문에 모형의 선택은 그리 중요한 문제가 아니다. 프로세스 개선에 사용되는 모형이나 기술들은 단지 수단일 뿐이지 그 자체가 목적이 되어서는 안 된다. 따라서 조직의 현 상황을 고려한 유연한 접근방법이 필요하다.

댓글목록

등록된 댓글이 없습니다.