김상기's Blog
SW 전문가를 향하여

(Essay#25) 논문 작성 과정

 

기말에세이로 어떤 내용을 작성해볼까 고민하다가 내년 2월에 있을 소프트웨어공학학술대회에제출하려고 작성해놓은 논문을 열어놓고, 곰곰이 생각해보니 이 논문을 작성하는 과정을 어떤 식으로 진행했는지를 에세이로 남겨보면 좋을 거 같아서 이번 글쓰기를 시작했다.

 

우선 논문 제목을 정하는데 가장 많은 시간이 걸렸다. 논문 제목을 정하면서 나는 항상 논문의 모든 내용을 포괄하면서도 어떤 내용인지 궁금하게 호기심을 자극시키는 제목을 짓기 위해 노력한다. 이번에 작성한 논문은 사실 별게 아닌 그 동안 회사에서 업무로 진행하였던 테스트 관리 도구를 도입한 내용을 정리한 것이다. 작년까지 우리 회사에 구축된 테스트 프로세스와 잘 연계할 수 있는 도구를 여기저기서 좀 찾아보고 써보면서 시범 적용을 한 내용이다. 그리고 빌드 자동화와 관련돼서 요즘 많이 쓰이고 있는 자동통합빌드 도구에 대한 내용도 같이 포함을 시켰다. 그러다 보니 논문 제목을 두 가지 도구의 도입을 모두 포함하도록 지으려다 보니 좀 힘들었던 거 같다. 이렇게 고민 끝에 짓게 된 논문 제목은 효과적인 테스트 관리를 위한 테스트 환경 구축 사례라고 결정하였다. 소프트웨어공학학술대회에 발표하는 산업체 논문은 일반 논문과는 다르게 업계에서 적용하고 있는 실제 소프트웨어공학 적용 사례를 요구하고 있기 때문에 대부분이 이런 사례 위주로 많이들 발표를 한다.

 

논문 제목을 정한 다음으로 진행했던 작업은 목차를 정하는 일이었다. 일반적인 논문이 연구배경à관련연구à본론à결론 순으로 작성이 되기 때문에 이 큰 목차를 기반으로 그 하위에 어떤 내용을 작성할지를 구상하였다.

 

연구 배경은 대부분 기존에 작성되어 있던 자료들을 많이 참조하여 작성을 하였다. 기본적으로 국방SW의 특징, 방위사업청 정책, 회사 내부의 테스트 활동 관련된 요구사항들에 대해서 간단히 설명을 하고 현재 회사에서 당면하고 있는 문제점들이 나타나게 된 배경을 설명하였다. 핵심이 되는 내용은 현재 연구개발 사업의 70%이상이 구현 및 테스트 기간이며, 조사된 데이터에 의해 이 테스트 기간이 프로젝트 별로 그 수준 차이가 크다는 것을 화두로 던졌다. 평균 30~60개월의 사업 기간 중 대부분의 기간을 테스트 활동을 수행하고 있으나 이를 체계적으로 관리하지 못하여 프로젝트 간 편차가 크다는 것을 논문에서 해결하고자 하는 문제점으로 지적하면서 연구 배경을 이끌어내었다.

 

관련 연구로는 ISO/IEC/IEEE 29119-2에서 다루고 있는 Test Processes를 살펴보고, 어떤 테스트 관리 활동을 표준에서 하도록 하고 있는지를 조사해보았다. 그리고 국내외 테스트 관리 도구를 비교 분석하여 장단점을 기술하고, 테스트 관리 활동에서 어떤 지표들을 관리할지를 관련 논문에 있는 내용으로 정리하였다. 관련 논문은 작년에 작성한 무기체계 SW 테스트 성과 지표 선정을 참조하였다.

 

본론에는 연구 배경에 화두를 던진 문제점에 대해 관련 연구를 바탕으로 해결방안을 제시하는  논문의 핵심 내용을 다루는 부분이다. 연구 배경에도 언급되었던 프로젝트 별 테스트 기간의 편차가 크게 나타나는 점을 해결하기 위해 테스트 프로세스를 표준화한 관리 시스템을 통해 테스트 관리 활동을 강화하는 해결방안을 제시하였다. ISO 29119 TMMi에서 중요하게 다루고 있는 Risk base testing을 기반으로 제품 위험à 테스트 컨디션à테스트케이스à테스트프로시저à결함으로 이어지는 각각의 테스트 데이터를 시스템에 등록하고 추적 관리하게 할 수 있는 테스트 관리 도구를 도입하였다. 또한 이렇게 축적된 테스트 데이터를 사내 테스트 성과 지표와 연결시켜서 자동으로 Reporting을 해주는 기능을 별도로 개발하였으며, 향후에는 이런 축적된 테스트 데이터를 자산화하여 재사용을 편리하게 할 수 있도록 시스템을 구성하였다. 또한 무기체계 소프트웨어에 대해 방위사업청에서 의무적으로 적용하고 있는 SW 신뢰성 시험(코딩규칙 검증, 실행시간 오류 검출, 코드실행률 확인)에 대해 코드 변경 시 재시험을 쉽고, 간편하게 할 수 있는 자동통합빌드 시스템을 구축하여 정적 분석 도구를 연동시켰다. 자동통합빌드 시스템을 통해 빌드 및 정적 분석 결과를 웹에서 즉각 확인하고 조치할 수 있으므로 개발 단계에서도 SW 신뢰성 시험을 수시로 수행할 수 있는 시스템을 구축한 것이다. 이 구축된 시스템을 통해 반복적인 시험 환경 설정 시간을 단축할 수 있으며, 여러 가지 분산된 빌드 환경을 통합관리하므로 테스트 모니터링 또한 강화되는 효과를 거둘 수 있었다. 마지막으로 본론의 뒷부분에는 각 시스템의 주요 기능에 대해 화면 정보와 함께 기능을 설명하였다.

 

결론에서는 본론에 정의된 핵심사항을 정리하고, 본 사례 연구를 통해 구축된 시스템으로부터 향후 어떤 일들을 더 해볼 수 있겠다는 형식으로 향후 계획을 기술하였다. 다양한 테스트 데이터를 분석하여 테스트 성과 지표 간에 상관 관계를 분석하고, 테스트 기간에 어떤 영향을 미치는지 그리고 이들 간에 통계적 관계를 바탕으로 SW 신뢰성 모델을 개발하여 이를 예측하는 연구 등을 앞으로 진행해볼 수 있겠다고 결론을 내렸다.

 

회사 내부의 SW공학 활동으로 진행했던 일을 논문으로 작성하다 보니 논문 작성 과정에서 그냥 막연하게 진행하던 업무들이 논리적인 연관관계가 있음을 자연스럽게 이해하게 되었고, 앞으로 더 확장하거나 개선해야 되는 일들도 식별할 수 있게 되는 계기가 되었다. 중요한 업무이거나 그렇진 않은 사소한 일들에도 그러한 현상 및 문제점이 나타나게 된 이유가 분명히 있을 것이고, 그것들을 해결하기 위해서 많은 또 다른 일들을 일반적으로 하게 된다. 논문을 작성하는 과정도 마찬가지인 거 같다.  무엇인가 한 주제에 대해서 내가 겪고 있는 문제점들이 있고, 그러한 문제점들은 이미 다른 분들도 겪었으며 또한 해결하려고 노력을 했을 것이고, 그 노력에 내가 조금 더 다른 방법으로 해결하고자 했다면 그러한 것들을 논문에 담으면 되는 것이다.

대학원에 입학하기 전에는 논문 작성이 정말 많은 지식과 노력이 필요하다고만 생각하였는데 이제는 내 주변에 조그마한 일들도 이런 논문 작성 과정과 같이 조금 더 고민해보고 해결하려고 노력을 했다면 아무리 사소한 노력들이라도 남들이 하지 않는 다른 방식의 것이라면 논문의 주제가 될 수 있으며, 또한 연구의 시작(끝은 아님, 반드시 연구의 문제가 실험적으로 해결되거나 효과가 있다고 증명이 되어야 연구의 끝이라고 할 수 있음)이 될 수 있다는 사실을 알게 되었다.  

CMMI High Maturity와 공인 심사

SW Engineering 2013. 11. 10. 21:31 by 김상기

(Essay#23) CMMI High Maturity와 공인 심사

 

벌써 11월이다. 이제 대학원 코스웍 수업도 1달 정도밖에 남지 않았고, 졸업 요건도 이제 대부분 마무리를 해서 최종 논문만 작성하면 되는 시점에 와있다. 올 한 해를 돌아보면서 가장 기억에 남는 일을 문득 떠올려보니 지난 8월에 있었던 CMMI 공인 심사가 생각이 나서 이번 에세이는 CMMI(Capability Maturity Model Integration)에 대해 한번 써보려고 한다.

 

CMMI에 대해서는 Software Engineering을 전공 한다면 모르는 분이 없을 정도로 잘 알려지고 있어 기본적인 설명은 생략을 하고, 그 중에서 Level 4, 5 High Maturity에 대한 설명을 조금 해볼까 한다. CMMI(v1.3 기준)에는 지금까지 성공한 프로젝트가 수행하였던 지키면 좋은 관행을 담고 있는 총 22개의 프로세스 영역이 존재한다. 이 중에서 Level 3까지 18개의 프로세스 영역이 있고, 나머지 4개의 프로세스 영역에서 High Maturity 조직에서만 수행 가능한 관행들을 다루고 있다.

 

4개의 프로세스 영역은 아래와 같다.

-       OPP (Organizational Process Performance, Level 4)

-       QPM(Quantitative Project Management, Level 4)

-       CAR (Causal Analysis and Resolution, Level 5)

-       OPM (Organizational Performance management, Level 5)

 

 위 프로세스 영역에서 요구하고 있는 사항을 요약하면 조직의 축적된 성과 데이터를 바탕으로 품질 및 프로세스의 PPB(Process Performance Baseline), PPM(Process Performance Model)을 개발하고(OPP), 이를 기반으로 프로젝트의 정량적인 관리(예측 포함) 활동을 통하여 프로젝트 목표 달성에 기여하며(QPM), 더 나아가 각 프로세스의 내재된 개선요소들을 지속적으로 분석하여 근본적인 원인을 찾고 개선해 나가며(CAR), 이러한 활동들이 프로젝트 및 조직의 품질 및 프로세스의 성과 향상을 점진적이고 혁신적으로 개선해 나가는(OPM) 활동을 말한다.

 

따라서, High Maturity 조직이 되기 위한 전제 사항으로 전체 조직 차원에서 데이터를 수집하고 이를 분석하여 활용할 수 있는 능력이 무엇보다 필요하다. 지금 생각해보니 현재 배우고 있는 데이터마이닝 과목에서 다루고 있는 기초 통계적인 지식과 함께 데이터를 의미 있는 하기 위한 모든 일들이 High Maturity 조직이 되기 위해서 필요한 것이다. 대부분의 대기업들은 6시그마, 낭비 제거, Lean 등의 혁신 활동을 수행하고 있는 것으로 알고 있다. 이런 6시그마에 나오는 통계적인 기법들도 바로 이런 High Maturity 조직에서 필요한 기초 지식이 된다.

 

운이 좋게도 나는 Level 5 기업에 소속이 되어 주관부서에서 일을 하다 보니 CMMI Level 5 공인 심사를 2번이나 내부 심사원으로써 참여하였다. Level 2, 3의 공인 심사와는 다르게 High Maturity 심사의 경우, 선임 심사원도 별도로 자격을 분리하여 국내에는 1명밖에 존재하지 않는 것으로 알고 있다. (Level 2, 3 20여명 존재)

 

High Maturity 조직 심사 시에는 일반적으로 다음과 같은 질문에 답을 할 수 있어야 한다.

-       프로젝트에서 예측을 위해 측정 지표를 일상적으로 사용하고 있는가?

-       프로젝트가 성공 가능한가?

-       만약 다른 프로세스를 적용한다면 어떤 결과가 예측되는가?

 

만약 당신이 위와 같은 질문에 바로 답할 수 없다면 High Maturity 조직에서 일하고 있는 것이 아니라고 생각하면 된다. 좀 더 쉽게 설명하자면 프로젝트 관리가 마치 네비게이션을 통해 길 찾기를 하는 것처럼 되어야 하는 것이다. 현재 시점에서 위치를 알고, 도착지를 입력하면 도착지에 갈 수 있는 여러 가지 길이 나타나고, 도착 시간이 예측이 되며 중간에 다른 길로 접어들었을 때 재 탐색을 하는 네비게이션의 동작 원리와 똑같이 현재 프로젝트의 성과 데이터를 입력하면 여러 가지 프로세스가 동작하여 프로젝트가 성공적으로 완료 할 때까지 소요되는 비용, 기간, 품질을 예측할 수 있는 조직을 말하는 것이다. 그리고 여기에 한 가지 더 이런 성과가 지속적으로 개선되는 조직을 말한다.

 

 내가 소속된 조직은 2007년 최초로 Level 5를 인증 받은 후 올해 3번째로 Level 5 인증을 받았다. CMMI 인증은 3년이라는 유효기간이 정해져 있기 때문이다. 3년마다 인증 심사를 하면서 느끼는 가장 큰 변화 요인은 시스템의 활용이 커지고 있다는 점이다. 2007년 인증 시에는 아마 EVMS 빼고는 대부분이 문서를 Evidence로 제시하여 심사를 받았는데 점차 문서들은 사내에 시스템으로 대체되고 있다는 것이다. 프로젝트 구성원들은 시스템을 통하여 그때 그때 필요한 정보들을 등록하고, 시스템을 통해 모니터링 하는 업무가 점차 증가하고 있다는 것이다.

 

프로젝트 구성원들은 평소처럼 일을 하면 자동으로 모든 측정 지표들이 수집되고, 이것들이 시스템적으로 분석되어 관리자에게 보고되는 그런 조직의 모습을 꿈꾸며 다시 한번 CMMI Level 5 기업에서 일하고 있다는 사실에 자부심을 다시 한번 가져 본다.

(Essay#22) EVMS의 역사와 방산업계 사용 사례


EVMS(Earned Value Management System)라는 용어를 들어본 적이 있는 분이라면 보통 프로젝트 관리나 비용 분석을 하는 업계의 담당자들일 것이다. IT개발자에게는 다소 생소할 수 있는 용어이지만 저번 수업 시간에 불스아이 차트를 수업 시간에 잠깐 다루다가 나온 용어이기에 이번 에세이 주제로 한번 삼아 봤다. 방산업계에서는 방위사업관리규정 제 95조에 의하여 3년 이상의 무기체계 연구개발사업에는 반드시 사업성관리기법(EVMS)와 목표비용관리기법(CAIV)를 사용하고 있다. 이번 에세이를 통해 우리 회사에서 사용하고 있는 현황도 잠깐 소개를 하려고 한다.

 

방위사업청에서는 국방획득분야의 과학적 사업관리 능력 향상을 위하여 과학적 사업관리기법 적용이라는 형태로 Systems Engineering(체계 공학), EVM(사업성과관리), CAIV(목표비용관리) 등을 사업에 적용할 것으로 명문화하고 있으며, 매년 이에 대한 적용 성과 발표회를 개최하여 방산업계 사용 사례를 공유하고 있다. 우리 회사도 매년 여기에 참석하고 있으며, 이번 10 31일에도 SE분야에 적용 사례를 발표하려고 준비하고 있다.

미국의 경우 1967년부터 비용/일정 통제시스템 기준(C/SCSC: Cost/Schedule Control Systems Criteria)을 연구, 제도화하여 국방 획득 관리에 적용해 왔다. 1997년부터는 이 C/SCSC에서 실적가치 관리체계(EVMS: Earned Value Management System) 기법으로 전환하여 사용하고 있다. 1999년에는 미국방부에서 EVMS를 미국 국가 표준(ANSI/EIA-748-1998)으로 채택, 이를 국제표준화 기구(ISO: International Standardization Organization)에서 국제 표준화하려는 노력이 진행되고 있다. 하지만 우리나라에서는 이와는 대조적으로 국방 분야보다는 민간 건설 분야에서 보다 많은 연구가 진행되고 있다.

EVMS의 핵심 개념은 실적 가치(EV: Earned Value)이다. 실적가치(EV)는 미 국방부 용어 정의에 따르면 수행된 작업의 가치를 예산 편성할 당시에 할당된 예산으로 환산한 값을 의미한다. 이 값은 계획된 예산이나 실제 지출된 비용과 비교하여 다양한 정보를 제공하게 된다. 현재 전통적인 방법으로 사업을 관리할 경우, 계획예산과 실제지출비용을 비교하여 사업의 실적을 표시하고 있으나, EVMS 기법으로 사업을 관리할 경우에는 실적가치를 추가로 산출하여 실적 판단 및 사업 분석에 이용한 것이 핵심이다.

EVMS를 적용한 사업관리 절차는 일반적으로 다음과 같이 이루어진다.  

1.     업무 범위 정의(Scope) : 업무 WBS 수립, 최소단위는 통제계정(CA : Control Account)라 불리며, 비용 및 일정의 성과 측정 기준 단위

2.     일정 계획 수립(Plan & Schedule) : 주공정 기법을 적용한 일정 계획 수립(CPM : Critical Path Method)

3.     예산 편성(Budget) : WBS 단위 기준으로 가능한 자세한 예산 편성

4.     기준선 작성(Baseline) : WBS, 일정, 예산을 바탕으로 통합된 일정과 비용 계획을 수립하여 기준선을 정함

5.     평가 및 감독(Estimate & Monitoring) : 비용성과지수(CPI), 일정성과지수(SPI) 산정

6.     성과 예측 및 조치(Forecast) : 비용과 일정의 편차를 지속적으로 관리하여 예측 및 피드백 수행.

 

우리 회사의 경우 EVMS SSPM이라 불리는 http://www.ptolemy.co.kr 에서 만든 시스템을 사용하고 있다. 사업이 시작되면 계약 단위로 CA 계정을 만들고, PV 값을 시스템에 입력하게 되어 있다. 그리고 매달 EV 값을 산정하여 입력하면 AC값은 자동으로 시스템으로부터 계산되어 아래와 같은 불스 아이 차트에 만들어진다. AC값은 그 달에 발생했던 재료비와 M/M ERP와 일보시스템으로부터 자동으로 집계되어 SSPM과 연동되어 계산되는 값이다.

매년 초에 사업 성과기준선 회의(IBL)을 통하여 PMB(성과관리기준선)을 통하여 최종사업비를 예측하고 있다. 방위산업이나 건설 사업에서는 무엇보다도 프로젝트 기간이 길기 때문에 EVM기법이 효과적으로 적용되고 있는 거 같다.

 

[Bull’s eye chart]




1 2 3 4 ··· 7 
분류 전체보기 (32)
개인 (7)
SW Requirement (0)
SW Design (0)
SW Development (0)
SW Testing (3)
SW Engineering (20)
SW 형상관리 (0)
09-14 09:38

공지사항

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백