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)을 혼동하여 위험관리를 제대로 못하고 있는 현실에서 아직까지 위험관리를 하고 있다고 말하고 표현하면서 확률모델을 사용하고 있지 않다면 위험관리를 하지 않고 있다고 볼 수도 있다.