개념: 레거시 통합
이 개념은 레거시 시스템을 갱신, 통합 또는 재개발하기 위한 로드맵을 정의합니다.
기본 설명
라이프사이클 사이의 활동:
  1. 소개
  2. 기준선 설정
  3. RUP 진행
  4. 전개 주기
  5. 요약
  6. 참조
추가 주제:

소개

레거시 시스템은 "새로운 비즈니스 요구사항 및 지속적으로 변화하는 비즈니스 요구사항을 충족시키기 위한 수정 및 전개를 방해하는" 시스템으로 정의되어 왔습니다. [1] 레거시 시스템은 일반적으로 오래된 대규모 시스템을 의미하며 이러한 측면에서 볼 때 "원래 RUP 이외의 프로세스를 사용하여 개발된 시스템"을 의미하기도 합니다.

여기서 "전개"란 레거시 시스템을 갱신, 통합 또는 재개발하기 위한 중요 프로젝트를 의미합니다. 따라서 이 로드맵은 RUP를 사용하여 성숙한 시스템을 지속적으로 유지보수하는 방법은 설명하지 않습니다.

일반적으로 가장 먼저 수행해야 하는 작업은 다음과 같은 질문에 대한 응답을 통해, 제안된 전개를 위한 비전을 정의하는 것입니다.

  • 레거시 시스템의 가치는 무엇입니까?
  • 원하는 전개 방법은 무엇입니까?
  • 계획된 전개를 지원하는 비즈니스 사례가 있습니까?

이 주제에 대한 자세한 내용은 가이드라인: 레거시 전개를 위한 비전 정의를 참조하십시오.

레거시 시스템 전개를 위한 일반적인 도전 과제는 다음과 같습니다.

  • 시스템에 대한 이해가 부족합니다.
    • 문서에 최신 정보가 없습니다.
    • 원래의 개발자가 없으며, 남아있는 인력은 실제 시스템이 작동하는 방법에 대한 제한적인 지식을 가지고 있습니다.
  • 시스템이 향후 개발 노력에 적합하지 않은 이전 소프트웨어 개발 방법 및 기술을 사용하여 개발되었습니다.

모든 프로젝트에서와 같이, RUP의 기본 원칙은 레거시 전개 프로젝트에 적용할 수 있습니다.

이러한 원칙은 다음과 같습니다.

  • 위험성 조기 완화
  • 반복적 개발
  • 구체적이고 측정 가능한 증거를 기반으로 한 진행상태 평가
  • 권한을 위임 받은 여러 소규모 팀 구성
  • 지속적인 품질 확인
  • 범위 관리
  • 필요한 중간 산출물만 생성

기본 RUP 라이프사이클 템플리트가 즉시 작성되며 해당 도입/인식(Inception), 정제(Elaboration), 구현/구축(Construction) 및 전이(Transition) 단계는 레거시 시스템 프로젝트에 완전히 적용됩니다. 또한 대부분의 RUP 프로젝트 관리 활동이 완전히 적용됩니다.

레거시 시스템 전개를 처리하기 위한 RUP(Rational Unified Process) 수정에 대한 자세한 내용은 아래에서 설명합니다.

기준선 설정

단순히 RUP 라이프사이클을 적용하는 것 이외에 RUP 진행을 위한 다른 원칙을 사용하려면 시작점을 설정해야 합니다. 레거시 시스템에 대해 설명하는 필수 중간 산출물의 최소 세트를 식별해야 합니다.

전개 범위에 따라 일반적으로 다음이 필요합니다.

  • 요구사항
  • 아키텍처 및 디자인
  • 테스트
  • 사용자 문서

RUP 중간 산출물의 이 기준선을 설정하면 레거시 프로젝트를 RUP 전개 주기처럼 진행할 수 있습니다.

RUP에 따라 프로젝트를 진행하는 데 사용할 수 있는 중간 산출물의 최소 세트를 설정하려면 레거시 시스템에 대한 리버스 엔지니어링이 필요합니다. 리버스 엔지니어링이란 원래 RUP를 사용하여 프로젝트를 개발한 것처럼 처리할 수 있는 충분한 정보를 식별, 추출 또는 재작성하는 것을 의미합니다. 프로젝트 관리자는 리버스 엔지니어링 노력을 시간 낭비라고 생각하므로 이 때 많은 프로젝트 관리자가 RUP에서 레거시 시스템을 폐기할 수 있습니다. 그러나 원래 의도가 모든 단일 중간 산출물을 재작성하는 것이 아닌 현재 시스템의 핵심 속성을 이해하고 변환 대상과 대체 또는 업그레이드 대상을 판별하는 것이므로 생각만큼 많은 노력이 필요하지는 않습니다.

이러한 중간 산출물의 RUP 템플리트와 함께 일부 연관된 가이드라인 및 체크리스트를 사용할 수 있지만 필요하지 않는 요소를 문서화하는 실수가 없도록 먼저 템플리트를 사용자 조정할 수도 있습니다. 일반적으로 템플리트는 첫 번째 전달 시 상호 참조(즉, 해당 정보를 찾을 수 있는 기존 문서 표시)로 "채울" 수 있습니다. 기존 문서가 HTML 온라인 문서인 경우 하이퍼링크를 사용할 수 있습니다.

이 기준선 설정 단계는 RUP 전용 단계는 아닙니다. RUP 진행을 위해 사용하는 프로세스 또는 방법에 관계 없이 기존 시스템의 리버스 엔지니어링을 수행해야 합니다. "Renaissance" 웹 사이트는 소프트웨어 리엔지니어링에 대한 Esprit 프로젝트로서, 리버스 엔지니어링에 대한 정보를 얻을 수 있는 훌륭한 소스입니다.

요구사항

레거시 시스템의 가장 훌륭한 가치는 새 시스템에 대한 요구사항 스펙으로서의 역할이라고 할 수 있습니다.

예를 들어, Rational Apex를 시작했을 때 비전 문서 초판에서는 "...우선 Rational Environment(Delta 버전)에서 수행하는 모든 기능을 같은 속도로 수행해야 합니다"라고 명기했습니다. 그런 다음 Rational Environment의 변형(추가된 기능, 삭제된 기능)을 지정했습니다.

현명한 팀에서는 레거시 시스템의 요구사항을 다시 문서화하지 않으므로 요구사항 노력을 처음부터 다시 시작하지 않아도 됩니다. 즉, 핵심 유스 케이스만 식별하면 됩니다. 일반적으로 이러한 유스 케이스는 현재 사용자 매뉴얼에 설명되어 있습니다. 유스 케이스 인벤토리를 확보(보고서: 유스 케이스 모델 조사)하는 것만으로도 충분합니다. 변경해야 하는 유스 케이스만 세부화하면 됩니다. 기능, 크기 및 성능 특성, 운영 체제, 메모리, 주변 장치, 기타 소프트웨어, 일반 제한조건 및 대부분의 "제품 관련 기술"과 같은 많은 비기능적 요구사항이 마케팅 또는 설치 문서에서 파생될 수 있습니다. 요구사항 관리 도구를 사용하지 않는 경우, 지금이 올바른 시작 시점입니다. 마지막으로, 이 리버스 엔지니어링을 수행하면서 작성할 추가 아티팩트는 레거시 시스템에서 사용되는 용어의 용어집으로서, 용어를 발견할 때마다 수집합니다. 용어집은 프로젝트 진행에 따라 그 가치가 향상될 수 있습니다.

아키텍처 및 디자인

레거시 시스템은 객체 지향(OO) 기법을 사용하여 완전히 다시 디자인하지 않아도 됩니다. 그러나 최소한의 아키텍처 정보는 필요합니다. 구현 보기에서 시작하여 최소 소프트웨어 아키텍처 문서를 작성할 수 있습니다. 다양한 서브시스템 또는 기본 코드 본문은 무엇입니까? 중요 인터페이스는 무엇입니까? 레거시 시스템이 분산된 경우 이 정보를 통해 배치 보기프로세스 보기를 식별할 수 있습니다. 기존 소프트웨어 인벤토리를 정확히 파악하여 각 요소와 요소 간 관계를 명확하게 식별해야 합니다. 아직 소프트웨어 형상 관리를 수행하지 않는 경우 이 시점에서 소프트웨어를 제어하면 됩니다.

인터페이스와 인터페이스 사용 방법 시나리오에 대한 설명도 중요합니다. 나중에 전개에 따른 영향을 받지 않는 서브시스템(레거시 시스템에서 안정적이고 재사용가능한 핵심 부분)을 식별합니다. 이러한 인터페이스 설명 이외에 자세한 소프트웨어 디자인 문서가 필요한 경우 해당 문서를 확보하고 신뢰할 수 있지만 변경해야 하는 부분을 알기 전에 문서 생성을 위해 지나친 노력을 기울여서는 안됩니다. 문서가 필요하더라도 사례별로 접근해야 합니다. 도구를 사용하면 며칠 간의 노력으로 이러한 리버스 엔지니어링을 수행할 수 있습니다.

또한 레거시 시스템에서, 이주하여 데이터 이주 스펙에 해당 데이터 프로파일을 기록해야 하는 다른 데이터 소스를 식별해야 합니다. 이 정보는 기존 데이터 소스와 새 시스템 버전에서 필요한 데이터 소스 간의 데이터 맵핑을 정의할 때 중요합니다.

테스트

레거시 시스템에 대해 개발된 모든 테스트, 테스트 스크립트, 테스트 사례 및 테스트 하니스는 일반적으로 새 시스템에도 적용할 수 있습니다.

사용자 문서

완전 수정에 따른 인센티브가 없는 한, 레거시 시스템의 사용자 문서는 새 시스템의 훌륭한 기준선이 될 수 있습니다.

RUP 진행

최소 RUP 중간 산출물 기준선(대부분 기존 정보 참조)을 설정하면 이제 다음 단계를 진행할 수 있습니다. 대부분의 RUP 타스크는 새로운 개발 프로젝트의 구현/구축(Construction) 및 전이(Transition) 반복에서와 같이 적용됩니다. 그러나 RUP에서 채택할 대상을 선택할 때는 가능한 최소 규모를 유지해야 하며 불필요한 타스크를 실행하거나 불필요한 중간 산출물을 작성해서는 안됩니다.

요구사항 관리

유스 케이스를 사용하여 새 요구사항을 표현합니다. 변경 내용을 정확하게 나타내기 위해 기존 기능성의 유스 케이스를 다시 작성해야 할 수도 있습니다. 여러 유스 케이스를 추가 또는 변경해야 하는 경우 용어집에서 소규모 도메인 모델을 도출하는 것이 바람직합니다.

아키텍처 및 디자인

새로운 개발 작업에 객체 지향 기법 및 UML(Unified Modeling Language)을 사용할 수 있습니다. 특히 시퀀스 다이어그램을 수행하는 경우, 영향을 가장 적게 받은 서브시스템을 대규모 컴포지트 클래스로 간주하는 간편한 기법을 사용할 수 있습니다. 결과 디자인 모델은 구조적으로 중요하거나 전개되어야 하는 클래스에 대한 세부 설명만 제공해야 합니다. 이러한 클래스에 대해 프록시가 작성될 수 있으며 해당 기능성은 기존 코드에 맵핑됩니다.

장기적인 목적이 모호하거나 레거시 시스템을 점진적이면서도 완전히 대체하기 위한 것인 경우 새 시스템의 아키텍처를 디자인한 후 기존 서브시스템에 맵핑해야 합니다. 기존 코드 본문에 랩퍼를 작성함으로써 OO 기법을 사용하여 디자인된 것처럼 나타낼 수 있습니다. 전체 시스템을 다양한 랩퍼로 다시 어셈블하는 작업은 정제(Elaboration) 단계의 내부 이정표가 될 수 있습니다. 유스 케이스 디자인을 수행하면서 유스 케이스 실현(realization)을 통해 다양한 기존 서브시스템에 대한 영향을 확인할 수 있습니다. 그런 다음 이 "랩핑된 서브시스템" 중 변환, 포팅, 재작성되거나, EAI(Enterprise Application Integration) 프레임워크에 통합되어야 하는 서브시스템을 결정할 수 있습니다.

데이터 이주 스펙은 소스-대상 데이터 맵핑으로 완료해야 하며 데이터 이주를 수행하는 데 필요한 이주 컴포넌트를 구현하는 데 사용됩니다.

경우에 따라 IBM Rational XDE 또는 Rose와 같은 도구를 사용하여 기존 코드 요소를 UML로 리버스 엔지니어링할 수 있습니다. 그러나 해당 결과 사용에 무조건적으로 의존해서는 안되며 항상 어느 정도 실제 사용자의 해석이 필요합니다.

배치

전개 범위에 따라, 새 시스템을 배치하는 것이 완전히 새로운 시스템을 개발하는 것보다 어려운 작업이 될 수 있습니다. 시스템을 새 아키텍처로 이주했거나 중요한 부분만 다시 개발한 경우, 전략을 선택해야 합니다. 즉, 이전 시스템의 핵심 부분을 새 시스템으로 옮기거나, 단계별 전략을 사용하여 전이 작업을 점진적인 단계로 수행해야 합니다. 새 시스템을 완전히 신뢰할 수 있을 때까지 두 시스템을 동시에 사용할 수도 있습니다. 실제로, 배치 작업의 경우 데이터 변환 및 이주, 오퍼레이션의 지속성, 인력 유지 등과 같은 문제로 인해 새 응용프로그램의 경우보다 레거시 시스템과 관련하여 민감한 부분이 더 많습니다. 이 배치 전략에 대해서는 배치 계획에서 설명합니다.

기타 원칙

모든 해당 타스크, 가이드라인, 기법 및 도구와 관련된 기타 소프트웨어 개발 원칙(예: 테스트 및 구현) 또한 적용됩니다. 형상 관리의 경우 기존 중간 산출물이 많고 관련 종속성 또한 복잡한 1일차부터 시작되므로 새로운 개발 작업의 경우보다 관련성이 높고 프로젝트 초기에서 필요합니다. 레거시 시스템 업그레이드에서는 변경 관리가 주요 활동이 됩니다.

일반적으로 레거시 시스템에 대한 재개발 결정은 비즈니스 모델링을 사용한 비즈니스 프로세스의 리엔지니어링 기회를 나타내며 이러한 경우 새 시스템에 다른 요구사항 세트가 필요할 수 있습니다.

전개 주기

레거시 전개 프로젝트는 모든 RUP 프로젝트와 동일한 단계 주기로 진행됩니다. 이러한 단계의 목표는 근본적으로 동일하지만 다음 섹션은 레거시 전개 프로젝트의 일부 특성에 대해 설명합니다.

도입/인식(Inception) 단계

RUP 도입/인식(Inception) 단계에서는 비전 문서 및 비즈니스 사례와 함께, 재작성해야 하는 중간 산출물을 지정하는 초기 개발 사례를 생성하도록 지정합니다. 이 단계에서는 또한 올바른 전개 전략을 선택하고 해당 비용을 예측할 수 있도록 요구사항 및 아키텍처와 같은 중간 산출물에 대한 리버스 엔지니어링 프로세스를 시작합니다.

정제(Elaboration) 단계

이 단계에서는 이전 중간 산출물을 새 도구 세트로 변환하는 작업을 포함하여, 진행해야 하는 최소 중간 산출물 세트인 RUP 기준선을 완료합니다. 이 작업은 단순 확장을 위해 하나의 단기 반복에서 수행할 수 있습니다. 그러나 이주 전략 또는 재개발의 경우와 같이 여러 아키텍처 변경사항을 수행해야 하는 경우, 이 정제 단계에서 여러 반복을 통해 새 아키텍처 기준선을 구현합니다. 경우에 따라 이 정제 단계가 핵심 단계이고 구현/구축(Construction) 및 전이(Transition) 단계에서는 작업이 거의 수행되지 않을 수도 있습니다. 새 환경에서 테스트가 수행되고 회귀 테스트를 초기에 시작할 수 있습니다. 완전히 새로운 시스템을 개발하는 경우의 정제 단계와 달리, 처음부터 많은 중간 산출물(특히 코드)을 관리해야 하며 변경 및 형상 관리 원칙의 타스크를 초기에 강조해야 합니다.

구현/구축(Construction) 단계

이 단계는 대부분의 작업에 새 코드 개발이 아닌 기존 코드와의 인터페이스 또는 기존 코드의 재작업이 포함된다는 점을 제외하고는 다른 RUP 프로젝트와 많이 다르지 않습니다. 추가 요소는 리버스 엔지니어링되고 다시 디자인되며 필요에 따라 문서화됩니다.

전이(Transition) 단계

전이 단계는 이전 시스템에서 새 시스템으로의 배치 전략에 따라 보다 민감할 수 있습니다. 위의 배치 섹션을 참조하십시오.

RUP의 반복 접근 방식은 각 반복마다 구체적이고 측정 가능한 목표를 갖고 있어 특히 레거시 전개를 단계별로 수행하는 데 유용합니다. 이와 관련하여 Rational Apex 프로젝트의 관리자인 Joe Marasco는 다음과 같이 기술했습니다.

"먼저 이동해야 하는 기능성, 영향을 주지 않고 이동할 파트 및 나중 반복에서 이동할 대상을 결정했습니다. AIX 버전이 안정화된 후 Sun OS에 대한 버전은 나중 반복으로 연기되었습니다. 누에고치에서 하루만에 나비가 되는 것과 달리, 지속적인 반복을 통해 해당 변화를 계획하고 전개를 추적해야 합니다. 다른 방법으로 복잡한 레거시 시스템의 전개를 관리하는 것은 상상할 수 없습니다."

요약

RUP를 레거시 시스템에 적용하는 방법은 다음과 같습니다.

  • 1. 수행하려는 작업을 이해합니다.
  • 2. 기존의 자산을 현명하게 활용합니다.
  • 3. RUP의 세부사항이 아닌 원칙에 초점을 맞춥니다.

RUP의 상당 부분은 수행하려는 전개 유형 및 확보하고 있는 레거시 시스템에 대한 정보에 따라 사용자 조정 및 형식성을 통해 레거시 시스템 전개에 사용할 수 있습니다.

레거시 시스템의 경우에도, 비전 문서(달성하려는 목적 설명), 프로젝트 계획(주요 이정표와 수행할 내용 표시), 반복 및 해당 특정 목표와 위험성 목록이 필요합니다. 또한 비즈니스 사례를 통해 프로젝트 수행에 따른 이점과 사용할 접근 방식을 나타내야 합니다.

기존 시스템에서 추출하거나 기존 시스템을 리버스 엔지니어링하는 방식으로 추가 RUP 중간 산출물을 개발할 수도 있습니다. 그러나 일반적으로 기존 문서를 RUP 형식으로 변경하는 것보다 계속 기존 문서를 사용하고 참조하는 것이 비용면에서 보다 효과적이므로 이 작업은 신중하게 수행해야 합니다.

한 가지 주의할 점은 동시에 너무 많은 변경사항을 시도하는 경우 프로젝트가 실패할 수 있다는 것입니다. 예를 들어, 프로세스 변경(예: RUP로 이동) 및 도구 세트 변경(예: Rational Suites로 이동)과 동시에 레거시 시스템의 주요 전개(예: 새 플랫폼으로의 이주)를 수행하는 경우입니다. 주요 레거시 전개를 수행하기 전에 프로젝트 초기에 새 프로세스 및 새 도구를 소개하는 경우 개발자가 RUP, 해당 철학, 해당 컨텐츠 및 지원되는 도구에 보다 친숙해질 수 있습니다. 또한 너무 많은 알려지지 않은 사항과 변경사항을 동시에 소개함으로써 프로젝트 위험성이 증가하는 것을 막을 수 있습니다.

참조

  1. Michael Brodie and Michael Stonebraker, Migrating Legacy Systems, San Francisco: Morgan Kaufmann Publishing, 1995.