SW 유지보수를 위한 재공학과 역공학

재공학은 SW를 새형태(form)로 재구성하기 위한 SW의 시험(examination) 및 변경(alteration)으로 정의되며, 뒤로 이어지는 새 형태의 구현 역시 포함하고 있다. 재공학은 가장 급진적(그리고 비싼)인 변경이지만, 소규모 변경에도 수행되기도. 재공학은 유지보수성 향상이 아니라 노후된 기존(legacy) SW를 교체하기 위해 종종 사용되기도 한다.

역공학은 SW의 컴포넌트와 이들간 상호관계 식별 및 또 다른 형태 또는 더 높은 추상 수준에 대한 표현물에 대한 생산을 위한 SW 분석 공정이다. 역공학은 수동적 속성을 지녀, SW를 변경하거나 새로운 SW를 만드는 활동이 아니다. 역공학은 제품 소스코드의 호출 그래프와 제어 흐름도의 생산에 초점이 맞춰져 있다.

역공학의 종류로는 재문서화(redocumentation) 및 설계 복구가 있으며, 리팩토링(refactoring)은 SW행동 변경을 배재한 상태에서 프로그램에 대한 재조직화를 통한 변형(transformation)으로, 프로그램 구조 향상을 위한 역공학의 한 형태다. 데이터 역공학은 최근 몇 년간 주목을 받아왔는데, 이는 물리 데이터베이스에서 논리 스키마를 복구하는 활동을 의미한다.

소프트웨어 유지보수

유지보수는 SW생명주기의 주요활동임에도 불구하고 대부분의 조직에서 타활동에 비해 덜 중요시 되었지만 이제는 SW개발에 투자하기 보다는 기운용되는 SW를 최대한 유지하려는
기조에 맞춰 주목받고 있는 상황이다. 과거 Y2K 문제는 SW유지보수에 좀 더 관심을 갖게 하였고 오픈소스 패러다임은 타인에 의해 개발된 산출물에 대한 유지보수의 필요성을 더욱 부각시켰다.

SW생명주기의 유지보수 단계는 보증기간 또는 인수의 후 구현 단계를 따라 시작되지만 유지보수 활동은 좀 더 일찍 시작된다. 유지보수는 사용자 요구사항을 지속적으로 만족시키기 위해 필요하며, 시스템은 수정적(corrective) 및 비 수정적 SW 행동으로 인해 변경된다. 유지보수의 목적은 결함 교정(correct), 설계 향상, 구현 향상, 타 시스템과의 연동(interface), 타 HW, SW, 시스템의 기능사용을 위한 프로그램 적용, 기존(legacy) SW 이전(migrate), SW 폐기 등이 있다.

유지보수자의 활동은 네 개의 주요 활동으로 요약될 수 있는데 SW의 일일 기능에 대한 제어 유지보수, SW 수정에 대한 제어 유지보수, 기존 기능의 완전화(perfecting), SW 성능의 수용 불가한 수준으로 낮아짐에 대한 방지로 나눌 수 있다.

유지보수는 제한된 이해와 테스팅, 영향분석, 유지보수성 등 기술적 이슈와 조직 목표로의 정렬, 유지보수자 형성, 프로세스, 조직적 측면, 외주 등 관리적 이슈, 유지보수 비용추정 이슈, SW유지보수 측정에 대한 이슈가 존재한다.

유지보수를 해결하기 위한 기법은 프로그램의 이해(Program Comprehension), 재공학(Reengineering), 역공학(Reverse Engineering)이 있다. 프로그래머는 변경 사항을 구현하기 위해 프로그램 읽기 및 이해에 적지 않은 시간을 보내는데, 코드 브라우저(browsers)는 프로그램 이해를 위한 핵심도구다. 명료하고 간결한 문서 역시 프로그램 이해에 많은 도움이 된다.

프로젝트 위험관리의 핵심과 기법

위험관리의 핵심은 아직 발생하지 않은 위험을 어떻게 관리할 것이냐가 중요하다. 현장에선 이를 위해 발생하기 전에 발생을 예고하는 조짐을 관찰하고 통제해야 한다. 위험이 발현될 것임을 알려주는 신호를 위험전이 경계지표(Trigger) 라고 한다. 즉 경계지표는 위험이 현실화되는 촉발점인 것이다.

프로젝트에서 도출되는 산출물중 변하지 않는 산출물은 없고, 불확실성도 제거할 수 없다. 변경을 통제하는 것보다 변경의 종류/규모/빈도를 예측하는게 훨씬 효과적일수도 있다. 세상에 같은 프로젝트는 존재하지 않으며 정확한 일정계획과 비용계획은 수립할 수 없다. 대부분의 프로젝트는 일정과 비용, 품질을 모두 만족시키기 어려운 조건으로 진행되기 때문에 위험관리는 필요한 것이다.

< SW개발 프로젝트의 위험관리 프로세스 >

위험은 불확실성으로 인한 잠재적 문제점이 된다. 따라서 위험은 확률모델로 정량화해야 한다. 이때 활용할 수 있는 도구가‘Risk Rating Matrix Analysis’다. 이 활동이 정량화 분석처럼 보이긴 하지만 사실은 정성적 분석이다. 이것을 통해 영향력을 예상할 수 있으며 각 위험의 우선순위를 파악할 수 있게 되는 것이다.

< 요구사항의 유연성과 위험관리 가이드(예시) >

위험관리의 정의도 중요하고 분석도 중요하지만 위험관리의 핵심은 리스크 다이어그램이다. 특정항목에 대한 불확실성을 확률기반 다이어그램으로 표시하는 것이다. 이러한 리스크 다이어그램은 몬테카를로 시뮬레이션을 통해 도출할 수 있다.

< 리스크 다이어그램(예시)과 도구를 사용한 산출물 >

< 몬테카를로 시뮬레이션(예시) >

리스크 다이어그램의 불확정 구간의 크기는 개발프로세스에 얼마나 많은 노이즈(불필요성 등)가 포함되어 있는지에 따라 결정된다. 프로세스 노이즈는 과거의 위험이 프로젝트에 미친 영향을 정량화 하여 표시한 결과다. 과거의 경험이 불확정 구간의 크기를 결정하는 것이다. 바로 어제의 문제가 오늘의 위험(Risk)인 것이다. 위험은 불확실성으로 인한 잠재적 문제점이라는 것을 명확히 인지해야 한다. 따라서 위험을 말할 때는 반드시 확률과 리스크 다이어그램을 참조해야 한다. 많은 사람들이 이슈(issue), 제약(constraint), 위험(risk)을 혼동하여 위험관리를 제대로 못하고 있는 현실에서 아직까지 위험관리를 하고 있다고 말하고 표현하면서 확률모델을 사용하고 있지 않다면 위험관리를 하지 않고 있다고 볼 수도 있다.

프로젝트 위험과 이슈에 대한 개념

SW개발 프로젝트의 수행에 있어서 위험요소는 지금까지 수행된 모든 프로젝트에 내제 되어 있음에도 불구하고 위험요소가 지닌 불확실성(발생가능성, 영향도, 대안의 적합성 등)으로 인하여 위험요소들을 추적하고 관리하는 것은 매우 어려운 현실이다.

SW개발이 단순 패키지가 아닌 통합시스템이라는 부분까지 확장되는 현실에서 프로젝트 수행의 규모와 복잡성이 점점 커지고 있다. 대규모 개발조직이 장기간에 걸쳐 다양한 구성요소들을 개발, 통합하게 되면서 각각의 위험요소들이 기하급수적으로 증가하게 되고 프로젝트 수행시 효과적인 위험관리가 프로젝트 성공의 핵심요인으로 부상하게 된 것이다.

프로젝트 관리자가 뛰어난 사람인지 아닌지를 판단할 수 있는 방법은 여러 가지가 있다. 그중 하나가 위험관리에 대한 부분이다. 위험에 대한 정의가 명확한 편인데도 불구하고 현장에서는 위험(Risk)과 이슈(Issue)에 대한 구분이 어려운 상황이다.

< 위험과 이슈 >

위험은 아직 발생하지 않은 확률적 사건이고 이슈는 발생해서 프로젝트의 발목을 잡고 있는 문제점이다. 결국 위험이 발견되면 이슈가 된다고 볼수 있다. 이것이 위험관리와 이슈관리를 혼동하는 주요 이유이기도 하다. 이러한 위험은 관리되어야 한다. 위험이 추상적인 상태에서는 문제로 되기전(이슈화 되기 전)에 대응책을 생각해 내는 과정인 것이다.

새로운 프로젝트 일정관리 소개

일정관리는 프로젝트를 납기일 이내에 완료하기 위한 계획수립과 통제활동을 의미한다. 모든 활동의 시작일과 종료일이 정의된 것을 일정이라고 부른다. 또한 일정은 달력에 표시할 수 있어야 한다가 전제다.

프로젝트 실패의 요인 중 하나인 납기를 통제하고 프로젝트 갈등과 품질, 비용, 일정의 상관관계를 고려했을 때 가장 통제하기 어려운 자원중 하나이며 기간 산정의 불확실성, 자원의 제한성으로 인해 잘못된 가정을 수립할 확률이 높은 분야다.

SW개발 프로젝트의 일정관리는 프로젝트 관리에서 가장 기초적이고 관리적 요소가 가장 많이 들어가는 부분이다. 현장에서의 일정관리는 도구 또는 파일을 통해 진척사항을 관리하고 있지만 세부 태스크별 활동까지는 연계하고 있지 못하고 있다. 그렇기 때문에 현장에서 가장 이슈가 되고 있는 것은 일정관리의 진척율 또는 진행상황이 객관적이지 못하고 주관적으로 표기되는 것이다.

현장에서 사용하는 일정관리는 대부분 아래의 그림처럼 나타내어 질 것이다. 일정관리의 대표적인 도구는 마이크로소프트사의 MSPROJECT로 도구를 사용하던 엑셀을 활용하던 대부분의 표현방식은 아래와 같다.

< 현장에서 사용하는 일정관리 시트(예시) >

하나의 총괄시트에 WBS나 활동들을 기준으로 나열하는 방식으로 전체적인 일정관리가 쉽지 않다. 도구에 따라서 해당 활동을 누르면 자원과 담당자들이 기술되기도 하지만 도구를 활용한다는 측면에서 한눈에 보고 관리하기가 쉽지 않다. 특히나 보여주기식 관리 시트라 실제 프로젝트에서 활용한다기보다는 발주자나 관리자에게 보고하기에 적합하게 구성되어 있다.

완벽한 형태의 일정관리라기 보다는 기존의 방식에서 조금더 개선된 방식이라고 보면 될 것 같다. 새로운 방식을 이용해 보고 싶거나 이러한 스케줄링 방식을 활용하고 싶은 엔지니어들은 edwardtufte.com을 통해 확인할 수 있다.



일정관리에 있어서 가장 좋은 방법은 유사사례에 대한 벤치마킹과 일정관리 SW공학도구의 적절한 활용이 프로젝트 성공의 열쇠라고 말할 수 있다.

SW개발 비용의 산정

현장에서의 비용산정은 아직도 공수 아니 M/M 방식의 투입인력 카운트에 의지하여 진행되고 있다. 미래창조과학부(구. 정보통신부)의 권고에 따라 기능점수 방식을 활용한 것이 벌써 9년(’04년 2월, 구. 정보통신부 고시 제 2004-8호)이 지났다. ’12년 2월 SW사업 비용산정을 기능점수로 산정하라는 권고가 ‘SW사업대가의 기준 일몰제’에 의해 고시 폐지되고 민간이양 되었지만 기획재정부의 예산편성지침에 매년 SW사업 예산편성시 기능점수를 권고하고 있어 공공부문에서는 기능점수 사용권고가 아직 유효한 상태다.

과거 제 살 깎기 경쟁에 내몰린 SW업계의 애로 해소차원에서 사업대가기준 산정 주체를 정부에서 민간으로 바꾸었지만 개선(안)을 제시하지 못해 업계혼란이 가중되고 있다. SW사업대가기준이 민간으로 이양되어 신뢰성이 떨어져 발주기관과 사업자간의 비용산정시 갈등만 더 커졌다는 것이 업계의 주장이다.

그럼에 불구하고 비용산정을 수행해야 하는 현장에선 어떻게 반응하고 있을까? 일부의 경우긴 하겠지만 사업대가기준이 없어졌다는 것을 빌미로 발주자에게 그들이 사용하고 있는 투입인력방식을 제시하고 있는 실정이다. 투입인력 방식이 나쁜 것은 아니다. 투입인력 방식을 도출하는 과정에 문제가 있기 때문에 기능점수방식을 권고한 것이다.


현장에서의 투입인력방식은 단순 인력 카운트만을 수행하고 투입인력별 노력(effort)을 산정하지 않는데 문제가있다. 'effort'를측정하는단위가바로기능점수인것이다. effort를측정하는 단위는 본수, 스텝수, 코드라인, 기능점수 등으로 분류되는데 본수와 스텝수 방식은 주관적인 요소가 포함되고, 코드라인방식은 개발자 스타일에 따라 차이가 나게 되므로 국제 표준인 기능점수를 권고하게 된 것이다.

비용산정 모델의 측면에서 보면 인력수는 결과이지 과정일수 없다. SW개발 비용의 산정은 규모파악을 통한 소요공수와 투입자원 및 소요기간을 파악하여 실행 가능한 계획을 수립하기 위해 비용을 산정하는 것이다. 발주자가 프로젝트 발주시 예정가격의 산정과 개발업자가
수주한 개발용역에 대하여 적정한 대가를 산정할 수 있는 기준으로 단위작업공수(비용)를 통한 총공수(총비용)를 산정하게 되는 것이다.

SW개발비를 산정할 때는 문제의 복잡도, 시스템의 크기, 신뢰도에 따라 프로젝트 요소를 고려하고 인적자원과 하드웨어자원에 대한 자원요소, 개발자 능력과 방법론에 따른 생산성 요소들도 고려하여야 한다.

< SW비용산정 모델시 고려요소 >

SW개발비용의 산정은 하향식 산정방법과 상향식 산정방법으로 나뉜다. 현장에서 가장 선호하는 방법은 하향식 산정방법으로 경험과 전문지식이 많은 개발자들이 참여한 회의나 토론을 통해 산정하는 방식이다. 하향식 산정방법은 전문가의 판단(expert judgment)과 델파이(Delphi)식 산정방법이 있지만 도출된 결과를 객관화하거나 정량화하기 힘들어 SW개발에서는 대략의 비용 사이즈를 도출할 때 많이 사용한다.

상향식 산정방법은 하향식 산정방법의 비과학성을 보완하기 위하여 개발할 시스템을 WBS 등으로 정의하고 각 구성요소에 대한 산정을 독립적으로 수행한 후 이를 합산하는 방식을 의미하며, 국내에서 가장 많이 활용되었던 SW사업대가기준에서 제시하고 있는 코드라인, 스텝수, 본수, 기능점수(FP) 등이 대표적인 방법이다.

프로세스와 프로젝트 매트릭스

SW프로세스와 프로젝트 지표는 SW프로세스 프레임워크 프로세스를 활용하여 수행하는 프로젝트에 대한 효과와 통찰력을 얻을 수 있도록 지원하는 정량적인 측정방법으로 기본적인 품질과 생산성 데이터를 수집하고 이 데이터에 대한 경험치 평균과 비교 분석하여 품질과 생산성이 향상했는지 여부를 결정하기 위해 진행된다. 또한, 측정을 통해 SW프로세스를 개선할 수 있도록 현황을 파악하는데 활용된다.

SW의 측정과 분석은 SW관리자에 의해 평가되고 SW개발자를 통해 데이터를 수집하게 된다. SW프로세스와 프로젝트를 측정하지 않는다면 결과는 주관적인 평가만을 통해 도출될 수밖에 없다. 측정을 통해 미래에 대한 준비 즉, 예측을 할 수 없게 되는 것이다.

프로세스 매트릭스를 구성하기 위한 측정은 모든 프로젝트 기간 동안 수집된다. 진행 중인 프로젝트의 상태를 평가하고 잠재적인 위험을 추적하고 중요한 문제 영역을 발견하거나 작업흐름 또는 작업을 조정하고 프로젝트 팀을 평가하는 등 프로젝트 매트릭스를 기반으로 SW프로젝트 관리가 가능하게 된다. 또한 프로젝트 팀에 의해 수집된 데이터들은 개선결과와 더불어 SW프로세스 개선에 영향을 미치게 된다.

< SW품질 및 조직의 효율성에 대한 결정 >

전략적 목적을 위해 사용되는 SW프로세스 측정과는 달리 SW프로젝트의 조치는 전술이다. 즉, 프로젝트 지표이며 이로 인해 파생되는 지표는 프로젝트 관리자 및 프로젝트 워크플로우, 기술 활동을 적용하는 SW개발팀에서 활용하게 된다.

대부분의 SW프로젝트의 프로젝트 지표는 SW를 개발하는 동안 발생한다. 과거 프로젝트에서 수집된 매트릭스의 노력과 납기 데이터들은 현재 SW개발을 위한 기초자료로 활용되는 것이다.

프로젝트 진행, 노력, 비용, 시간의 측정은 기존 추정치와 비교될 때 모니터링되고 이러한 데이터를 관리 가능하게 해주는 것이다. SW기술작업이 시작될 때 다른 프로젝트 매트릭스들은 의미를 가지고 시작하게 된다. 모델 도출, 검토시간, 기능점수 및 소스코드의 측면에서 생산성이 측정된다. 또한 각 SW개발 작업 중에 발견된 오류들이 추적되기도 한다.

SW의 발전으로 설계시 요구사항은 기술 매트릭스를 통해 설계품질을 평가하고 소스코드 및 테스트에 소요되는 방식에 영향을 미치게 된다. 프로젝트 매트릭스의 목표는 두가지다. 첫째는 프로젝트의 지연을 방지하고 잠재적인 문제 및 위험을 완화시키고 일정을 최소화하는데 활용된다. 둘째는 지속적으로 제품의 품질을 평가하는데 사용하고 필요시 품질향상을 위한 기술방식을 수정할 수 있게 되는 것이다. 결함 측정을 통해 결함을 최소화 시키면 개발품질의 향상을 통해 프로젝트 기간 동안 필요한 재작업의 양 또한 감소하게 되고 이는 전체 프로젝트 비용의 감소로 이어지게 된다.

SW공학의 최우선 목표는 적시에 높은 품질의 시스템 또는 SW제품을 생산해 내는 것이다. 이 목표를 달성하기 위해서는 검증된 SW프로세스 내에서 현대적인 도구와 효과적인 결합을 통해 적용해야 한다. 매트릭스는 요구사항의 품질과 설계모델, 소스코드, 테스트 케이스를 평가하기 위해 활용될 수 있다.

< SW매트릭스 수집 프로세스 >