2016년 3월 8일 화요일

프로젝트 수행 - 비용산정 편

시스템 운영은 물론이고 일반적인 개발 프로젝트에서도 소프트웨어의 단가보다는 인건비 위주로 비용을 산정하는 경우가 많다. 어렵게 산정된 비용도 발주자의 과도한 절감 요구와 과다 경쟁으로 더 낮게 수정되는 경우가 많이 일어난다. 하드웨어인 경우는 적정 가격이 있어 비용산정이 쉽지만 소프트웨어는 쉽게 판단할 수 없기 때문이다.
영업이나 프로젝트관리자는 프로젝트가 시작하기 전에 적정 비용산정 때문에 자주 고민에 빠진다. 소프트웨어 비용은 직관적인 정량화가 어려워 개발 기간, 투입 인력의 경력과 인력 수 등을 고려하여 정성적으로 판단하는 경우가 많지만, 최근에는 발주자와 수주자 간의 신뢰 확보를 위해 비용산정을 위한 객관적인 산정기법이 도입되는 추세다.
이번에는 소프트웨어의 개발 비용산정 방법에 대해 살펴보고자 한다. 일차원적인 비용산정부터 세부 기술의 난이도를 고려한 비용산정까지 살펴본다.

소프트웨어 개발 비용산정의 구성
비용산정의 정의는 “소프트웨어 개발에 필요한 기능과 규모를 기반으로 직접적으로 투입이 필요한 비용을 예측하는 과학적이고 합리적인 활동”이라고 할 수 있다. 비용산정을 통해 발주자는 소프트웨어의 합리적인 가격을 확인할 수 있고, 개발자는 개발에 필요한 정당한 비용을 요구할 수 있다.

일반적인 비용산정의 구성
한국소프트웨어산업협회의 소프트웨어사업 대가산정 가이드를 보면, 소프트웨어 개발 비용은 인건비와 그에 따르는 제경비, 기술료 등으로 구성된다(그림 1 참조).

<그림 1> 소프트웨어사업 대가산정 가이드

- 직접인건비 = 투입인력 소요공수 X 노임단가
- 제경비 = 직접인건비의 110 ~ 120%
- 직접경비 = 소프트웨어 개발사업에 소요되는 직접적인 경비
- 기술료 = 직접인건비와 제경비 합의 20 ~ 40%

개발자들의 등급을 특/고/중/초로 구분하여 단가를 매기고 투입기간에 따라 인건비를 산정한다. 제경비와 직접경비, 기술료는 인건비에 따라 산정되기 때문에 소프트웨어를 고려한 항목은 거의 없다고 볼 수 있다.

보완된 비용산정의 구성
지금까지도 소프트웨어의 비용산정은 월 단위 인력투입(MM; Men per Months)로 하는 경우가 일반적이다. 이 방식은 <그림 1>을 기초로 하여 한국소프트웨어산업협회가 제시하였다. 이후, 인건비만으로 소프트웨어 개발비용을 산정할 수 없다는 의견이 많아 소프트웨어의 규모와 기술보정을 반영하여 보완되었다.
보완된 소프트웨어 개발 비용산정 방식을 살펴보면, 소프트웨어를 개발하는데 필요한 원가와 프로젝트에서 사용되는 직접경비, 이익으로 구성된다(그림 2 참조).
<그림 2> 소프트웨어 개발 비용산정 방식

- 개발원가 = 소프트웨어 개발규모 X 단가 X 기술보정
- 이익 = 개발원가의 10 ~ 20% 내외

<그림 2>의 방식은 <그림 1>의 월 단위 인력투입이 아닌 소프트웨어의 개발규모를 산정한 후 단가를 곱한다. 그러면, 소프트웨어 개발의 원가가 산정되고, 기술보정 계수를 곱하여 만들고자 하는 소프트웨어의 기술수준을 반영한다. 이 값에는 <그림 1>의 제경비, 기술료가 포함되어 있다.
<그림 2>의 이익은 <그림 1>에는 없는 항목으로 개발팀의 판단에 따라 정해지는 것이지만 일반적으로 10 ~ 20% 내외로 잡는 경우가 많다.  더 보기 >>>

젠킨스를 이용한 정적분석 자동화 방법

얼마 전, 한 미국의 유명 주간지에서 전세계 250명의 비즈니스 및 IT 담당 임원에게 실시한 설문 조사 결과가 기사화된 적이 있다. 응답자의 66%가 ‘소프트웨어 품질’에 의해 기업의 미래가 좌우될 것이라고 보고 있으며, 소프트웨어 품질·속도·디지털 고객 경험이 디지털 혁신을 좌우할 것으로 생각하는 것으로 나타났다.

이처럼 소프트웨어 개발에 있어서 품질은 매우 중요한 부분이다. 개발자들은 누구나 품질이 중요한 부분인지 알고 있지만, 인력과 시간 등 여러 가지 요인에 의해서 실제 품질보증을 위한 활동은 미흡한 경우가 많다. 품질 보증을 위한 활동 중의 하나인 ‘정적분석’이 무엇인지, 정적분석을 자동화하기 위한 방법은 어떤 것들이 있는지 기업 ECO 의 박대우 팀장을 통해 알아본다.

< ECO 정보시스템사업4팀 박대우 팀장  / 정보관리기술사 >



Q: 소프트웨어 개발에 있어서 품질이 중요한 이유가 무엇이라고 생각하시는지요?

높은 품질의 소프트웨어란 제품의 목적의 만족도에, 주어진 기간에, 정해진 예산으로 제품이 생산되는 것을 말합니다. 품질의 어원을 살펴보면 Qualitas/Qualis(어떤 성질에 관한: of what kind)에서 유래한 것을 알 수 있는데요. 과거에는 물품 자체가 지닌 고유의 성질, 특성, 개성, 기술, 경제적인 품질 측면 등을 품질이라 정의하였지만, 현대에는 고객의 요구를 충족시키는 명시적이고 묵시적인 것까지 정의에 포함합니다. 정리해보면, 제품이나 서비스가 가져야 하는 요건에 대한 ‘일치성’과 용도에 대한 ‘적합성’ 등의 명시적 또는 묵시적 요구를  만족시키는 능력에 관한 특징 및 특성의 총체를 품질이라 말할 수 있습니다.
SW 품질에 대해서 여러 학자들은 이 부분에 대해서 다양한 의견을 말하고 있는데요. 이는 SW 품질이 다른 개념에 비해 정량적으로 평가하기 힘들기 때문입니다. 품질에 대해 다양한 견해가 있지만, IEEE의 정의를 보면 다음과 같습니다.

- 기능명세서의 적절한 구현성 등 주어진 요구사항을 만족시킬 수 있는 SW의 총체적인 특징과 제품의 특성들
- SW가 요구하는 특성이나 속성들을 융합할 수 있는 SW 프로세스 정도
- SW가 고객의 기대에 만족해야 하며 이를 사용자나 고객이 인지할 수 있는 정도
- 일반적으로 사용되는 SW가 고객의 기대를 만족시켜 품질을 인정받을 수 있는 특성들

오늘날, 우리는 컴퓨터의 역할이 더욱더 증대하고 있는 세상에 살고 있는데요. 컴퓨터를 구성하는 요소 중, 가장 중요한 것은 소프트웨어입니다. 다양한 산업이 발달함에 따라 소프트웨어의 역할은 더욱더 중요해지고 있는데요. 특히 최근에는 사회·문화 전반에 걸친 다양한 활동에 소프트웨어를 이용하고 있죠. 산업계, 금융계, 학술적 연구 등 어떤 분야든지 적절한 소프트웨어 없이는 효율적인 업무 수행을 기대하기 힘든 것이 현실입니다. 모든 사람이 더욱 컴퓨터와 소프트웨어에 의존하여 작업하고 있는 것이죠.

이렇게 소프트웨어의 역할이 증대됨에 따라, 잘못된 소프트웨어로 인해 야기되는 문제들 역시 속속 보고되고 있습니다. 몇몇 대표적인 예는 다음과 같습니다.

- 1979년 미국에서 발사한 첫 번째 비너스 위성은 포트란 프로그래밍의 콤마 하나를 잘못 표기함으로써 의도하지 않은 방향으로 날아가 버렸다. 그 결과 당시 천만불 이상 투입된 프로젝트가 물거품이 되는 결과를 초래했다.
- 2000년 우체국은 새로운 금융시스템을 도입했는데, 이 때 프로그램 오작동으로 인하여 약 보름 간 우체국의 모든 시스템이 마비되는 사건이 있었다.
- 2001년 인천 신공항 개항 시, 물류시스템 소프트웨어의 문제로 짐이 뒤섞이고 사라져서 고객에게 많은 불편을 야기했다.
- 2001년 12월 국내에서 출시된 유명한 게임이 낮은 품질과 버그 때문에 전량 리콜을 단행해야만 했다.
- 지난 2년 여 동안 게임 기사를 보면, 월 평균 2-3개 정도의 게임이 계획된 출시 날짜를 연기했는데, 그 사유는 여러 가지 요인이 있었다. 그 중 품질에 관련되어 출시를 연기한 경우가 전체 경우 중 80%이며, 55개였다. 세부 내용은 테스팅 등 품질평가를 통해 버그를 찾고 수정하기 위한 것이거나, 게임의 완성도를 높여 고품질의 게임을 만들기 위한 것이었다.

위의 몇몇 사례가 소프트웨어에서 발생하는 모든 에러를 나열한 것은 아닙니다. 실제로 보고되지 않은 사례가 더 많겠죠. 소프트웨어 공학적인 측면에서 살펴보면, 이러한 문제점은 그냥 간과할 수 없는 심각한 것입니다. 소프트웨어는 궁극적으로 고객의 만족과 필요에 의해 개발하고 판매되는 제품이기 때문에 좀 더 높은 품질의 소프트웨어를 제작할 필요가 있다고 할 수 있습니다.

IoT 서비스 구축 동향

IoT Platform을 구성하는 Device, Service, Software 요소의 역할과 유기적 기능, 그리고 이 구성의 발전 동향을 살펴볼 수 있습니다.  

발표자: 김영욱 부장(Microsoft사 기술엔지니어)