유지보수와 역공학 (2)

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

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

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

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

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

유지보수와 역공학 (1)

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

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

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

리스크관리 (위험과 이슈)

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

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

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

 

 

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

비용산정

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

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