1. 서 론
소프트웨어공학에서 말하는 소프트웨어란 프로그램과 프로그램의 개발, 운용, 보수에 필요한 관련 정보 일체를 말한다. 소프트웨어에 프로그램 이외의 문서와 정보를 포함시키는 이유는 이들 모두가 소프트웨어 생산 작업의 결과이기 때문이다. 또한 프로그램은 프로그램 언어로 작성된 코드, 즉 정적인 표현을 의미하지만 소프트웨어는 프로그램이 컴퓨터를 가동시킨다는 동적인 의미를 포함하고 있다.
소프트웨어 개발 프로젝트는 고객의 요구사항에 맞추어 기능, 품질 등을 충족하고 정해진 기간 내에 소프트웨어 제품을 개발하고 인도하는 사업을 말한다. 과거의 소프트웨어 개발 프로젝트는 소수의 탁월한 능력을 가진 프로그래머에 의해 만들어지고 관리 되었다. 그러나 소수의 인원만으로 개발하는 규모를 넘어서면서, 근래에는 소프트웨어 개발의 성패가 집단의 프로젝트 관리에 대한 숙달 정도에 크게 좌우되게 되었다. 하지만 중소기업 SW개발 현장은 아직도 소수 개발자의 능력에 따라 기능과 품질이 정해지고 있으며, 잦은 인력이동 등으로 회사 및 프로젝트 존폐가 위험할 정도로 안정성을 보장하기 힘들다[1,2].
본 논문에서는 이러한 문제점들을 해결하기 위하여 과거에 사람들이 SW품질에 대해 제각각 정성적으로 확인하고 테스트 하던 것을, 검증되고 공개된 open source 품질관리 툴들을 활용하여 체인화하고 가시화하여, 정량적으로 관리할 수 있도록 중소규모 개발사에 맞는 SW품질관리 방법을 제시한다[3].
2. 관련연구
2.1 IBM의 품질관리
IBM에서는 Rational이라는 품질관리 솔루션을 만들어 품질관리를 자동화하고 있으며 솔루션 형태로 배포하고 있다. IBM Rational 소프트웨어 품질관리 솔루션은 요구사항-테스트 계획/케이스-테스트-결함에 이르는 결과의 연관성 및 추적성을 제공하여 조기 결함발견 및 문제해결을 도와 개발프로세스 후반의 리스크를 감소시킨다. Fig. 1은 IBM의 SW품질 관리체계를 나타낸다. 이제품의 경우 고가의 금액을 통해 중소규모가 아닌 대규모 프로젝트에 사용되어지고 있다[4].
Fig. 1.Configuration of IBM Rational SW Quality Controll Solution.
2.2 구글의 SW품질관리
구글에서는 생산성 혁신팀(Engineering Productivity Team)이라 불리는 별도 조직에서 소프트웨어 테스팅을 담당한다. 생산성 혁신팀은 개발자와 테스터의 툴 체인을 수행하고, 단위 테스팅 부터 탐색적 테스팅에 이르는 모든 분야의 테스팅과, 그에 관련된 공학적인 방법을 만들며, 검색, 광고, 앱, 유튜브 등모든 웹 특성과 관련된 공용 툴과 테스트 인프라스트럭처를 다룬다.
구글은 생산성 혁신팀을 통해 속도와 규모에 관한 여러 가지 문제를 해결했으며, 대기업이 되었음에도 불구하고 시작단계의 벤처와 같은 속도로 소프트웨어를 제공할 수 있게 하였다. 구글 초창기에 생산성 혁신팀은 2백 여명에서 2013년에 1,200 여명으로 성장하였으며, 구글 테스팅 블로그는 매달 십만건의 페이지뷰를 보여줬고, GTAC(Google Test Automation Conference, www.GTAc.biz)는 SW테스팅 분야에서 주요 학회로 성장하였다. 이런 현상들을 보면 구글은 자체 자동화 툴을 이용하여 많은 테스터들이 품질관리를 진행하고 있으며, 자동화 툴을 기반으로한 테스트들이 SW품질관리에 중요한 역할을 하고 있음을 알 수 있다[5].
2.3 NAVER 소프트웨어 품질관리
NHN에서는 품질전략을 QP 프로세스라 정의하고 결함 예방(Defect Prevention)을 강화하기 위해 개발과정에서 수행해야 하는 NHN의 SW개발 품질을 전반적으로 점검한다.
어떤 조직의 개발 프로세스를 효과적으로 변경하는 방식에는 ‘빅뱅’ 방식과 ‘점진적 적용’ 방식이 있다. 빅뱅 방식이란 기존의 개발 프로세스를 일시에 변경하는 방식을 말한다. Salesforce.com의 경우 빅뱅 방식으로 3개월 만에 회사 개발 조직의 모든 개발 프로세스를 변경하여 효과를 보았다. 빅뱅 방식과 반대되는 점진적 적용방식은 개발 프로세스를 일시에 변경하는 것이 아니라 개발 수행 활동을 조직에 서서히 내재화한 후 점차 넓혀가는 방식이다. 점진적 적용 방식은 빅뱅 방식의 부작용 중의 하나인 조직의 반발을 최소화 할 수 있다는 장점이 있으나 지속적인 관리와 지원이 없다면 장기적으로 진행하기 어려운 단점이 있다.
NHN에서는 두 가지 적용 방식의 장점을 결합하여 적용하되 기본은 ‘점진적 적용’방식이며 초기 개선안을 자발적으로 지원한 팀에 적용한 다음, 효과가 검증되면 회사 개발 조직에 확산하여 적용하는 방식을 취하였다. 이는 상위 관리자의 지속적 지원과 조직원들의 자발적 참여가 결합된 NHN의 고유한 개선 방식이라 할 수 있다.
소프트웨어 개발 프로세스 측면에서 NHN은 ‘신속한 효과’를 목표로 삼았다. 소프트웨어 개발 프로세스는 크게 기획/설계 단계, 구현 단계, QA 단계로 나눌 수 있다. 기획/설계 단계에는 많은 유관 부서의 인력들이 얽혀 있고 단기간에 이 과정을 개선하기에는 어려움이 따른다. NHN에서는 이런 조직 상황을 고려하여 한꺼번에 모든 개발 프로세스를 혁신한 것이 아니라 신속하게 효과가 나타나는 범위부터 시작하여 점진적으로 전체 개발 프로세스로 넓혀가는 개선 전략을 사용하였다. 따라서 기획 단계보다 개선방법을 적용하기가 비교적 쉬운 ‘구현’과 ‘QA’단계에서 먼저 QP를 시작하였다[6].
Fig. 2.Introducing Process of NHN’s QP.
2.4 소프트웨어공학센터 SW시각화
2.4.1 소프트웨어공학센터의 SW시각화 개요
좋은 결과를 위해서는 과정에 대한 엄밀한 관리가 필요하다. 마찬가지로 좋은 SW를 얻기 위해서는 SW개발과정 전반에 대한 관리가 중요하며 이는 곧 SW개발 프로세스로 표현될 수 있다. 따라서 성공적인 SW개발 관리를 위해서는 SW 자체, 즉 소스 코드와 SW개발 프로세스에 대한 관리가 필요하다.
SW공학 프로세스는 이러한 관리를 위한 전통적인 방법이다. 그러나 SW공학 프로세스에 의한 SW 개발 품질관리를 수행하기에는 그 방법이 매우 전문적이며 국내의 중소기업은 인력 및 비용이 부족하다. 이러한 현실에서 국내 중소기업이 SW개발 품질관리를 수행하기 위한 현실적인 방안이 필요한 시점이다.
SW시각화는 이러한 방안으로 시각화, 문서화를 제안한다. 첫 째, 시각화는 SW개발의 가장 어려운점인 SW 비가시성을 극복함으로써 SW개발의 전체 과정을 파악할 수 있도록 하며, 이를 통하여 SW개발 품질 관리를 실현하고자 한다. 둘 째, 문서화는 기업의 개발 노하우 관리 및 내부 인력간의 업무 이해도 향상과 특정 상황에서외부와의 의사소통을 위한 방안이다.
Fig. 3.Conceptual Diagram of SW Visualization.
즉, SW시각화는 소스코드와 개발 프로세스를 관리하는 것을 목적으로 하고, 시각화 및 문서화를 그 방안으로 하여 SW개발 품질관리를 수행하기 위한 것이다. 이에따라 소프트웨어공학센터에서는 ①개발 프로세스의 시각화, ②소스코드의 시각화, ③소스 코드의 문서화, ④개발 프로세스의 문서화라는 4방향으로 SW개발 품질관리를 정리하고 있다[7].
2.4.2 체계적인 품질관리를 위한 SW 시각화 주요 지표
SW개발과정을 효과적(Effective)이고 효율적(Efficient)으로 관리하기 위해서는 개발과정과 개발 SW에 대한 정량적인 측정을 통해 현재 상황에 대한 객관적 인식과 제어에 필요한 기초자료가 필요하다. 이는 SW개발에 있어서 파악하기 어려운 SW개발과정과 품질 현황을 다양한 이해관계자(관리자, 발주자, 개발자, QA 등)가 이해하기 쉽도록 정량적 수치로 표현한 것으로, SW를 시각화하기 위한 주요 지표이며 Table 1과 같이 개발과정과 품질검증영역으로 구분하여 제시하였다[8].
Fig. 4.SW Visualization Activities by Process.
Table 1.Quality Control Index for S/W Visualization
2.4.3 SW시각화 시스템
SW시각화 시스템은 SW개발에 있어, 앞의 “SW 시각화 품질지표”에서 정의한 지표를 목표로 하여 SW시각화 시스템의 활용을 SW개발에서의 수행 활동으로 정의함으로써 SW 품질을 확보하고자 한다.
SW시각화는 SW공학 프로세스를 기초로 각 품질 지표를 정의하고 시스템을 구성하며, 각 단계별 개발 방법론 및 Tool 사용에 관한 가이드를 제공한다. Fig. 는 SW시각화의 요구사항 관리, 구현, 테스트, 형상 관리의 4가지로 구분하여 개발하는 프로세스별 활동을 나타낸다[8].
요구사항 관리 단계는 요구사항을 정의하고 변경을 관리하는 과정이며 구현단계는 다시 개발과 빌드의 두 단계로 구분하여 구성한다. 테스트 단계는 정적 분석과 동적분석으로 구성하며, 형상관리는 개발과정 전반에 걸쳐 수행되는 단계로, 개발산출물을 관리하고 변경을 통제한다[8].
2.4.4 SW시각화 시스템 구성요소
SW시각화 System은 지속적 통합, 형상관리, 요구사항, 테스트 케이스 관리, 통합개발환경, 테스트 자동화의 각 부분이 상호 연결되어 동작한다. 요구사항 관리 시스템으로 입력된 요구사항에 따라 개발된 산출물은 형상관리 시스템을 통하여 관리되고 형상 관리 시스템의 개발 산출물은 지속적 통합을 통하여 지속적으로 빌드된다. 이렇게 빌드된 결과는 테스트 자동화 시스템에 의하여 정해진 시점에 자동으로 테스트되어 현재 SW의 품질을 측정하고 그 결과를 시각화한다. 또한 테스트 케이스 관리 시스템에 의하여 요구사항 대비 구현상태의 검증을 위한 테스트 케이스가 관리되고 검증결과에 따라 요구사항의 구현률이 시각화된다. 이러한 SW시각화 시스템이 상호 연결되어 동작함에 따라 SW 품질 시각화의 결과에 대한 원인을 파악하고, 빠른 결함 조치가 이루어질 수 있도록 지원한다. Fig. 5에 SW시각화의 시스템 구성을 나타내었다[8].
Fig. 5.Components of SW Visualization System.
2.4.5 S/W시각화에서 제시하는 Tool Chain
소프트웨어공학센터에서는 SW시각화를 위한 Tool Chain을 Fig. 6과 같이 제안하였다[8].
Fig. 6.SW Visualization Tool Chain.
수행부분은 실제 개발시 진행되는 단계 즉 요구사항-개발-형상관리-빌드-테스트 과정을 표시하였으며 검증은 SW시각화에서 제시하는 방법론을 시스템 부분에서는 개발시 진행되는 단계에 사용되는 오픈소스를 자바 기반과 닷넷 기반에서 사용되는 툴들을 나열하였다. 가이드와 Tool가이드 부분은 이 시스템에 사용되는 Tool과 SW시각화 가이드를 표시한 부분이다.
3. 시각화를 기반으로 한 중소규모형 SW품질관리 방법
3.1 연구의 목적 및 방법
2장에서 기업들의 SW품질관리 방법들에 대해서 알아보았다. IBM에서는 Rational Rose라는 툴을 해외의 많은 기업들이 도입하여 좋은 사례들을 만들어내고 있지만 국내에서는 비싼 비용을 지불해야만 사용할 수가 있고 중소규모에는 많이 무겁고 부담스러운 부분이 있어 소프트웨어공학적 개념 및 이론만 참조하기로 하였다. 구글의 품질관리 방법은 인력 및 관리툴을 혼합한 방법이었지만 품질관리 조직을 10명 이상씩 두어, 개발인원이 50명 이하인 중소규모 회사에서 관리자를 교육하고 테스트를 하는 경비적인 부담이 커서 도입이 쉽지 않다. 세 번째로 검토한 NHN의 품질관리 방법은 자체적인 네이버의 품질관리 툴들을 사용하고 또, 오픈되어 있어서 도입을 검토해 볼만 하다. 그리고 소프트웨어공학센터의 SW 시각화 프로젝트 결과는 수정을 거치면 충분히 도입할 수 있다고 판단하였다.
NHN과 소프트웨어공학센터의 툴은 차이가 있는데, NHN은 50% 이상 자체 품질관리 툴들을 개발하여 사용하였고 소프트웨어공학센터는 100% 오픈소스 기반으로 툴 체인을 구성하였으며, 품질관리 체계도 차이를 보였다.
본 연구에서는 소프트웨어공학센터 SW시각화라는 품질관리 기법 안에 NHN의 장점들을 차용하고 소프트웨어공학센터에서도 제안하지 않은 툴들을 조사하여, 실제로 중소규모의 SI사업에 적용하여 소프트웨어 품질과 고객의 만족도, 원가절감과 개발자들의 마인드 변화 등을 조사한 결과를 가지고 중소규모에 맞는 Tool-chain을 제안하고자 한다. SW품질 관리의 효용성을 증명하기 위한 실험은 다음의 전제 조건을 가진다.
첫째 본 연구는 소프트웨어공학센터에서 제시하는 SI형 사업의 품질관리를 기반으로 하며 표준 품질지표를 기반으로 한다.
둘째 총 60가지의 오픈소스 기반의 품질관리 툴들 중에서 java 기반의 오픈소스 툴들로 한정한다.
셋째 개발기간이 6개월 이상 12개월 이하의 SI 프로젝트를 기준으로 하며, 인원은 5명 이상 10명 미만으로 구성된 프로젝트를 대상으로 한다.
넷째 단계는 요구사항-개발-형상관리-빌드-테스트-문서화 -고객만족도 조사 순으로 7단계의 품질관리 및 만족도 조사를 기본으로 한다.
다섯째 개발방법론은 일반적으로 모든 개발에서 사용되어져 온 마르미III의 CBD개발방법론에 준하여 진행되었으며, 문서 산출물 또한 동일하게 마르미 III 또는 고객사가 요구하는 추가의 문서들을 포함한 정도의 산출물 목록을 기준으로 한다.
3.2 중소규모의 SW시각화 기반의 품질관리 Tool-chain 제안
품질관리의 7가지 단계에 사용되는 Open Source 60여종 중 3가지 형태의 테스트를 통하여 Fig. 7과 같은 툴 체인을 제안한다. 본 논문에서는 Fig. 6에서 제시하는 개발 프로세스를 Fig. 7과 같이 요구사항관리, 개발, 형상관리, 테스트, 빌드 순으로 단순화하고 프로젝트 관리는 별도의 이슈로 뽑아내어 총 5가지의 프로세스로 단순화 하였다. 먼저 요구사항 즉, 이슈관리에서는 Redmine과 요비닷컴 그리고 유료버젼인 JiRa가 검토되어졌다. 그 결과 요비닷컴 이슈관리는 한국프로젝트에 맞게 잘 관리되어지나 전체적인 프로젝트 관리 측면에서 Redmine을 따라오지 못했다. JiRa는 3가지 툴 중 성능이 가장 나았지만 유료 버전이어서 10user 이하일 경우는 부담이 되지 않으나 그 이상일 때는 중소기업이 사용하기 부담스러운 액수가 책정되어 배제하였다. 또한 개발환경은 IDE 환경인 Eclipse와 메이븐 구조를 선정하였으며, 형상관리는 Subversion을 선택하였다. Subversion은 현재 현업에서 가장 많이 사용되고 있는 형상관리도 구이며 테스트 개발자들이 빈번하게 사용해 왔기 때문에 별도의 교육 없이 적용 할 수 있어 선택하였다. 그 이외에 CVS 나 VSS라는 형상관리 오픈소스들이 존재하지만 Subversion은 속도가 빠르고 커밋 실패시 롤백이 가능한 장점이 있다. 테스트의 경우 시큐어벅스 등 여러 가지 툴들을 검토하였으나 사용자 측면에서 SonarQube가 있는 다양한 플러그인을 통해 코드검사에서 단위 테스트까지의 테스트 관련 사항의 대부분을 처리할 수 있기에 해당 툴을 선택했다.
Fig. 7.Configuration of Tool-Chain for Small and Medium Scale SI Projects.
마지막으로 빌드에 있어서는 Hudson과 Jenkins가 검토되어졌으나 비슷한 사양임에도 불구하고 Jenkins가 무료로 배포되고 있어서는 Jenkins를 선택하였다[9]. 이 툴들의 선택 기준은 첫째 오픈소이면서 한국개발자들이 사용하기 편하도록 UI 및 설명이 잘 되어 있는가, 둘째 국내 개발자 커뮤니티 사이트의 평이 좋으며 업데이트가 빈번히 일어나는가, 셋째 타 오픈소스와의 기능 평가에서 우위에 있는가를 기준으로 선정하였다.
수많은 도구들 중 어떤 도구를 사용하여 프로젝트를 진행할 것인가는 각자가 가질 수 있는 선택이며, 본 연구에서 중요한 부분에 해당한다. 또한 어떠한 조합으로 가장 높은 이익을 얻을 수 있을지에 대한 부분 역시 본 연구의 핵심이 된다. 사실 3개월 안쪽의 간단한 프로젝트나 디자인적 요소가 70%이상을 차지하는 프로젝트는 SW시각화를 생각하여 개발관리를 진행하는 것이 오히려 비현실적이고 비효율적일 수 있다. 그렇다고 1년 이상의 대규모 프로젝트에서만 SW시각화를 생각하고 진행해야하는 것도 아니다. 우리나라 SW산업에 있어서는 50% 이상이 SI 로 이루어져 있으며, 6개월에서 1년 정도의 개발 기간을 갖는 프로젝트들이 대부분이다. 중소규모의 SW개발 현실은 개발양이 많은데 비해 기간은 짧고, 용역 금액도 낮은 편이다. 중소규모 SI에서 SW시각화는 SW개발과 유지보수의 효율성을 높여서 실제 중소규모 SI업체에 큰 도움을 줄 수 있지만, 자칫하면 부하가 가중되어 역으로 프로젝트의 발목을 잡는 현상이 발생할 수도 있다. 이런 현실에 걸맞게 SW시각화의 구성 또한 경량화가 필요하며 무엇보다 최적화된 툴 구성으로 프로젝트의 품질을 높일 수 있어야 한다. 결국 중소규모의 프로젝트에서 가장 중요한 것은 수익률을 높이는 것이며, 이는 SW품질을 높여야만 가능하다. 즉, SW 시각화 품질관리용 툴 구성 시에 필요한 도구들은 모두 오픈소스 기반의 무료 툴들 이어야 하고, 빌드 및 배포의 자동화를 통해 개발 기간을 단축시킬 수 있어야 한다. 그리고 자동화된 코드 검증과 프로젝트관리를 통해 프로젝트의 품질 향상을 촉진시켜야 한다. 우리는 경량화된 SW시각화 개발툴 구성을 Fig. 7과 같이 실무에 맡게 구성단계를 축소하였으며 개발자의 부담을 줄여 줄 수 있는 최소한의 구성으로 제안한다.
SW시각화 도구들은 오픈소스 기반의 무료 툴들로 구성되었으며, 모두 5가지 Tool-chain으로 경량화하였다.
Eclipse IDE를 가지고 개발을 진행하며 Subversion을 통하여 형상관리를 한다. 이때 Subversion은 중앙 저장소 서버를 두고 개발 클라이언트는 Eclipse Plug-In을 통하여 Commit / Update를 수행한다. 개발과정 중 단위 테스트 및 코딩 스타일, 코드 검증에 대한 부분은 SonarQube를 활용 하며, 개발자 레벨에서의 테스트 뿐 아니라 배포 레벨에서의 테스트까지 SonarQube를 활용하여 진행될 수 있도록 한다. 빌드에 대해서는 Maven을 활용하며, Maven을 통해서 라이브러리 의존성 해소까지 해결을 한다. 이를 바탕으로 지속적 통합(CI)은 Jekins를 사용하여 소스코드의 일관성을 유지시키고 자동빌드까지 할 수 있도록 한다. 마지막으로 전체적인 이슈 트랙킹이나 프로젝트요구사항에 대한 적용 관리에 대한 부분은 Eclipse 개발 레벨에서 Mylyn을 통해 task를 취할 수 있도록 하고 전체적인 부분은 Redmine과 Mylyn을 연계하여 관리 할 수 있도록 한다.
3.3 SW품질관리 실험 및 평가
소프트웨어 개발노력을 측정하는 모델을 설정하고 유효성을 증명하기 위하여 사례연구를 통한 시스템 복잡도를 계산하는 연구가 있다.[10]
우리는 많은 소프트웨어 프로젝트 개발을 해왔으며 2013년1월부터 2014년 8월까지 진행되었던 프로젝트를 사례 중심으로 실험하였다. A project는 고객사 자체 품질관리 방법론을 기반으로 하며 B Project 는 소프트웨어공학센터에서 제안하는 품질관리 방법을, C Project는 본 논문에서 제안하는 품질방법을 통해서 7단계의 품질관리 체계를 분석한다.
Table 2은 SW품질관리방법의 효용성을 증명하기 위한 3가지 프로젝트의 실험조건을 나타낸다.
Table 2.Experimental Conditions
3.3.1 A Project
A Project는 7명이 총 10개월을 진행한 대기업 프로젝트였다. 개발방법론은 애자일과 CBD가 혼합된 형태였으며 상주 형태로 진행되었다. 이 프로젝트의 품질관리 체계는 외주를 준 개발조직과 실제로 사용되는 사용조직이 상이하였으며 단위모듈별로 개발후 외주사 개발조직이 먼저 테스트를 진행하였고, 이후 사용조직이 다시 한번 실제 상황을 가정해 테스트를 하고, 통과하면 다음 모듈 개발 및 테스트로 넘어가는 구조였다.
품질관리 도구는 개발을 위한 자바의 IDE환경인 이클립스 그리고 UI를 위한 가우스, 형상 관리를 위한 Subversion을 사용했으며 그 이외에 툴들은 사용하지 않고 모든 테스트를 수동으로 진행하였다.
이 프로젝트에 대한 결론을 말하면 실패로 끝났으며 프로젝트 종료 후 납기 지연을 이유로 지체 가산금까지 물게 되는 최악의 결과를 낳게 되었다. 프로젝트 조직은 최상위 조직으로 꾸려졌으나 개발사의 커뮤니케이션 미숙, 외주사의 품질관리 방법론 오류, 범위산정의 오류 등 많은 문제가 들어났다.
그 중 가장 문제가 되었던 부분이 품질관리 부분 이었으며, 사용조직과 검수조직, 테스트 조직이 상이하여 모두 주관적인 판단으로 문제를 지적하고 개발자가 이를 개선해 나가는 방식이었는데 이 방법은 개발을 지연시키고, 개발조직과 운영조직이 부산과 대전, 서울로 나뉘어 있어 원활한 의사전달이 이루어지지 않은 것도 문제였다. 이유 없는 실패가 없듯이 A 프로젝트는 많은 이유와 오점을 남기고, 개발 기간 2개월 초과 후 서비스를 개시했으며, 결국 지체 가산금을 물게 되었고 개발자들의 사기도 떨어뜨리게 되었다. 우리는 이 프로젝트 이후로 SI사업에 있어 품질관리 자동화가 얼마나 중요한지 알게 되는 계기가 되었다.[11]
3.3.2 B Project
B Project는 툴을 이용한 품질관리방법론을 적용 하였으며, 소프트웨어공학센터에서 제안하는 Tool-chain을 적용하였다. 단, 커뮤니케이션은 Redmine을 사용하지 않고 별도의 웹상에 helpDesk을 게시판 형태로 만들어 운영하였다.
이슈트래커와 기타 커뮤니케이션 기능은 네이버의 오픈소스 기반 요비닷컴을 활용하여 프로젝트 진행에 부족한 부분은 보충하였다. 개발인원은 6명이었고 총 7개월 투입되어 개발되었으며 UI 툴로는 Flex를 사용하였다. 첫 단계부터 6명이 하나의 실에 상주하며 매일 오전 회의를 통하여 개발 방안을 논의하고 그 다음 현업 담당자들과 만나 요구사항 분석, 화면설계 검증 구현(개발), 테스트 품질관리, 형상관리, 이슈관리, 단위테스트, 전체 테스트 오픈까지 짧은 일정에도 모두 참여하여 프로젝트를 완료 하였다.
B Project는 절반의 성공이라고 할 수 있다. 소프트웨어공학센터에서 제안하는 툴들에 익숙하지 않아 먼저 툴을 숙지하면서 적용하다보니 일부 개발자들로부터 일을 위한 일이라는 불평을 듣게 되었고, 기간 내 완료했지만, 고객이 시스템 운영에 어려움을 겪게 되는 사항이 일어났다. 그래서 추가 6개월 동안 개발자 1명이 상주하며 교육 및 운영 서버 환경체계를 인수인계 해주게 되었고 개발은 제 시간에 완료 되었지만 인계 단계가 추가된 것이다. 툴사용 결과로 C Project를 수주하는 계기가 되었지만 현재에도 외주사는 전체 프로세스가 어려워 일부 툴들은 사용하지 않는 상황이 생겼다. 하지만 B 프로젝트에 참여했던 초급 개발자가 B 프로젝트에 참가하지 않았던 중급 개발자를 능가하는 품질관리기법을 익히게 되었고 개발자들의 인식이 바뀌는 계기가 된 프로젝트였다.
3.3.3 C Project
A, B Project를 토대로 개발자와 고객의 인식을 변화시키고 Tool-chain을 단순화하여 C 프로젝트에 적용하였다. C Project 진행을 위해 소프트웨어공학센터에 컨설팅을 의뢰하였고, 다양한 자료를 찾아서 활용할 소스도 많이 확보하여 Fig. 7과 같은 프로세스로 구성하였다. 결국 C Project는 개발자들의 현실에 맞춘 요구를 고려하여 단순할 정도의 품질관리 프로세스인 Fig. 7을 도입하였다. 툴들이 많이 축소되었지만, 사용 시 업무지연 및 사용상의 문제, 고객 교육의 문제로 품질 및 개발 프로세스를 수정하였으며, 결국 최적화된 5단계 프로세스에 6가지 툴을 사용하는 형태로 프로젝트를 마치게 되었다.
최적화 Tool-chain을 사용한 C Project는 총 7개월의 기간에 월 6명이 투입되었으며, 계획된 일정으로 납기 내에 프로젝트를 완료하였다.
A, B Project에 비해 많이 개선되었지만, 납기에 맞추기 위해 총괄 PM, 개발 PM, 개발자, 품질관리자 등의 조율에 의한 진행이 많아져서 Tool-chain을 충분한 테스트하지 못한 아쉬움이 남는 개발이었다.
그러나, 품질관리 툴 도입이후 개발자와 고객이 모두 만족하는 프로젝트라고 평가할 수 있는 결과물이 도출 되었으며, 유지보수 또한 고객이 직접 할 수 있는 툴 자동화를 이루었다는 점에서 성공적인 프로젝트라 할 수 있다.
3.3.4 A,B,C Project 비교
세 프로젝트의 실험결과를 Table 3으로 정리하였다. 시각화 SW품질관리 Tool-chain을 적용여부에 따른 효율성 향상을 정량화된 수치 데이터로 보여주기는 쉽지 않다. 그러나, Table 3에 나타낸 여러 항목들을 살펴보면 C Project가 가장 효용성 및 만족도가 높음을 보여준다.
Table 3.Experimental Results of Project A, B, and C
4. 결 론
소프트웨어 공학센터에서 제시한 SW시각화 구성은 다음 3가지 문제점을 가지고 있다.
1) 너무 많은 툴의 사용으로 추가 업무로 인식하여 개발자로 하여금 품질관리라는 개념 자체를 부정하게 하는 원인을 제공한다.
2) 중소규모의 소프트웨어 개발상 7～10인 정도의 인력이 투입됨을 가정했을 때 구성원의 역할과 롤이 세분화 되어 있어 품질관리 인력의 증원이 불가피하다.
3) 많은 품질지표에 따른 관리 포인트 증가로 인한 업무의 스트레스가 가중된다.
우리는 위의 문제점들을 해소하기 위해 세분화된 역할을 중소규모에 맞게끔 축소하고 품질관리는 프로젝트 팀 외의 사업지원팀을 따로 두어 별개로 운영하며, 많은 툴 중 개발자의 역량을 강화시킬 수 있는 툴 사용법의 권장을 통해 개발자 인식변화를 시도하였다. 또한 복잡한 Tool-chain을 중소규모에 맞는 Tool-chain으로 간소화하고 소프트웨어공학센터에서 시도되지 않은 또 다른 오픈소스의 유, 무료 툴도 포함시켜 좀 더 효율성이 높도록 품질지표를 향상시켰다.
그 결과, A,B,C Project 중 C Project는 모두 만족할 만한 성과를 가져왔으며, Table 3과 같이 관리자, 개발자, 고객 모두 이전보다 만족도가 상승됨을 알 수 있었고 품질 및 납기도 20% 이상 향상되었음을 확인하였다
대부분의 중소규모 프로젝트 기간이 7~10개월이기 때문에 다양한 툴 조합을 통해 더 많은 테스트를 해보지 못한 점이 아쉽다. 또한, 새로 시작하는 프로젝트의 경우 SW시각화 Tool-chain에 대한 부족하여 품질관리를 여분의 일로 인지하는 경우가 많고, 개발회사 또한 개발자 능력에만 의존해서 납기내 개발을 최고의 목표로 추진해 왔다. 품질관리를 도입한 프로젝트를 진행하면서 개발자들은 인식의 변화가 일어났고 조금씩 관심을 보이는 경향이 있다. 향후 좀 더 많은 툴들의 조합을 구성하여 효율성이 높고 단순화된 Tool-chain을 신규 프로젝트에 투입 해봄으로써 중소규모에 맞는 SW시각화를 지속적으로 추진할 예정이다.
References
- H. Kim, H.J. Lee, J.B. Kim, and J.I. Kim, "Quality Control on the Basis of Software Visualization for Developing Small and Medium Scale Software Systems," Proceedings of The 10th International Conference on MITA2014, HongKong, pp.270-271, 2014.
- J.W. Bae, J.M. Song, J.B. Kim, and J.I. Kim, “Quality Control Tool-Chain Proposition on the basis of Software Visualization for Developing Small and Medium Scale Software Systems,” Proceeding of The Korea Multimedia Society Autumn Conference, Vol. 17, No. 2, pp.136-137, 2014.
- G.S. Ha, Software Project, Sang Neang Publishing, Paju, 2014.
-
IBM Rational Software.
http://www-01.ibm.com/software/kr/rational/index.html , (accessed October, 6, 2014) - J. Whittaker, J. Arbon, and J. Carollo, How Google Tests Software, Acorn, Uiwang, 2012.
- S.M. Yoo, S.H Lee, S.B. Lee, E.H. Kim, J.C Na, J.H Yoon, et al., NHN does like this!Software Quality Control, Wikibook, Paju, 2010.
- Ministry of Science, ICT and Future Planning, Software Engineering White Paper, NIPA SW Engineering Center, 2013.
- Ministry of Science, ICT and Future Planning, SW Develop Quality Control Manual, NIPA SW Engineering Center, 2013.
- Y.G. Jang, Continuous Integration using Hudson, Insight, Seoul, 2012.
- S.K. Park and M.G. Park, “A Model to Estimate Software Development Effort Based on COSMIC-FFP Using System Complexity,” Journal of Korea Multimedia Sosiety, Vol. 13, No 11. pp.1575-1585, 2010.
- J.B. Kim and J.I. Kim, “A Study of Successful Project Management based on MaRMI III & Agile Development Methodolodgy,” Proceeding of The Korea Multimedia Society Autumn Conference, Vol. 16, No. 2, pp. 64-65, 2013.
Cited by
- Cloud Native환경에서의 생산성 향상을 위한 어플리케이션 개발 방법 연구 vol.23, pp.2, 2015, https://doi.org/10.9717/kmms.2020.23.2.328