소프트웨어 공학: 재사용 기반 소프트웨어 엔지니어링 - 비용 절감과 품질 향상을 위한 전략

 

 

 

 

목차

 

 

---

이 글은 Ian Sommervile의 "Software Engineering, 9th Edition"에 기반하여 정리되었습니다.

재사용 기반 소프트웨어 공학(Reuse-based software engineering)은 기존 소프트웨어를 재사용하는 것에 중점을 둔 소프트웨어 개발 전략입니다. 비록 재사용이 개발 전략으로 제안된 것은 40년 이상 전이었지만(McIlroy, 1968), 실제로 2000년 이후에야 ‘재사용을 통한 개발’이 새로운 비즈니스 시스템의 표준이 되었습니다. 재사용 기반 개발로의 전환은 소프트웨어 생산 및 유지보수 비용을 줄이고, 시스템을 더 빠르게 제공하며, 소프트웨어 품질을 향상시키려는 요구에 대응하기 위해 이루어졌습니다. 

 

재사용 가능한 소프트웨어의 가용성은 과거에 비해 많이 증가했습니다. 특히 오픈 소스 운동으로 인해 저렴한 비용으로 이용할 수 있는 방대한 재사용 가능한 코드 베이스가 생겨났습니다. 이는 프로그램 라이브러리나 전체 애플리케이션의 형태로 제공될 수 있습니다. 또한 특정 회사의 요구에 맞춰 조정 및 적응할 수 있는 많은 도메인 특화 애플리케이션 시스템들 있습니다. 일부 대형 기업들은 고객을 위해 다양한 재사용 가능한 컴포넌트들을 제공합니다. 웹 서비스 표준과 같은 표준들은 일반적인 서비스를 개발하고 이를 다양한 애플리케이션에서 재사용하는 것을 더 쉽게 만들었습니다.

 

재사용 기반 소프트웨어 공학의 예로는:

1. 애플리케이션 시스템 재사용: 애플리케이션 시스템 전체를 다른 시스템에 변경 없이 통합하거나 다른 고객을 위해 애플리케이션을 구성하여 재사용할 수 있습니다. 또는 공통 아키텍처를 가진 애플리케이션 패밀리를 개발하되, 특정 고객에 맞춰 조정할 수도 있습니다.
2. 컴포넌트 재사용: 애플리케이션의 컴포넌트, 즉 서브시스템에서 단일 객체에 이르기까지 다양한 크기의 요소들을 재사용할 수 있습니다. 예를 들어, 텍스트 처리 시스템의 일부로 개발된 패턴 매칭 시스템이 데이터베이스 관리 시스템에서 재사용될 수 있습니다.
3. 객체 및 함수 재사용: 수학 함수나 객체 클래스와 같은 단일 기능을 구현하는 소프트웨어 컴포넌트를 재사용할 수 있습니다. 이 형태의 재사용은 표준 라이브러리 형태로 오랜 시간 일반적으로 사용되어 왔습니다. 특히 수학 알고리즘 및 그래픽과 같은 분야에서는 효율적인 객체와 함수를 개발하기 위해 특화된 전문 지식이 필요하므로, 이 접근 방식이 특히 효과적입니다.

소프트웨어 시스템과 컴포넌트는 잠재적으로 재사용 가능한 개체이지만, 그 구체적인 속성으로 인해 새로운 니즈에 맞게 수정하는 데 비용이 많이 들 수 있습니다. 이를 보완하는 재사용 형태는 ‘개념 재사용’으로, 소프트웨어 컴포넌트를 재사용하는 대신 아이디어, 작업 방식 또는 알고리즘을 재사용합니다. 재사용되는 개념은 구현 세부 사항이 포함되지 않은 추상적 표기법(예: 시스템 모델)으로 표현되며, 따라서 다양한 상황에 맞춰 구성되고 적응될 수 있습니다. 개념 재사용은 설계 패턴, 설정 가능한 시스템 제품, 프로그램 생성기와 같은 접근 방식에 활용될 수 있습니다. 개념이 재사용될 때, 재사용 프로세스에는 추상적 개념을 인스턴스화하여 실행 가능한 재사용 가능한 컴포넌트를 생성하는 활동이 포함됩니다.

 

소프트웨어 재사용의 명백한 장점은 전체 개발 비용이 줄어들어야 한다는 것입니다. 요구사항 명세, 설계, 구현 및 검증해야 할 소프트웨어 컴포넌트의 수가 줄어들기 때문입니다. 그러나 비용 절감은 재사용의 유일한 장점이 아닙니다. 다음 표에서는 소프트웨어 자산 재사용의 장점을 설명하고 있습니다.

소프트웨어 재사용 장점	설명
높아진 신뢰성 (Increased dependability)	기존 시스템에서 사용되고 테스트된 소프트웨어를 재사용하면 새로운 소프트웨어보다 더 신뢰할 수 있습니다. 이미 설계 및 구현상의 결함이 발견되고 수정되었기 때문입니다.
프로세스 리스크 감소 (Reduced process risk)	기존 소프트웨어의 비용은 이미 알려져 있지만, 새로운 소프트웨어 개발 비용은 항상 추정의 영역에 있습니다. 이는 프로젝트 관리에 중요한 요소로, 프로젝트 비용 예측의 오차 범위를 줄여줍니다. 특히 대규모 소프트웨어 컴포넌트(예: 하위 시스템)를 재사용할 때 더욱 그렇습니다.
전문가의 효율적 활용 (Effective use of specialists)	반복적인 작업을 수행하는 대신, 애플리케이션 전문가들이 그들의 지식을 캡슐화한 재사용 가능한 소프트웨어를 개발할 수 있습니다.
표준 준수 (Standard compliance)	사용자 인터페이스 표준과 같은 일부 표준은 재사용 가능한 컴포넌트 세트로 구현될 수 있습니다. 예를 들어, 사용자 인터페이스의 메뉴가 재사용 가능한 컴포넌트로 구현되면 모든 애플리케이션에서 동일한 메뉴 형식을 사용자에게 제공합니다. 표준화된 사용자 인터페이스를 사용하면 사용자가 익숙한 인터페이스를 접하게 되어 실수를 줄여 신뢰성이 향상됩니다.
개발 가속화 (Accelerated development)	시스템을 가능한 한 빨리 시장에 출시하는 것이 전체 개발 비용보다 더 중요한 경우가 많습니다. 소프트웨어를 재사용하면 개발 및 검증 시간이 단축되어 시스템 생산 속도가 빨라질 수 있습니다.

 

그러나 재사용과 관련된 비용과 문제점도 있습니다.(아래 표 "소프트웨어 재사용 단점 참조) 특정 상황에서 컴포넌트가 재사용 가능 여부를 이해하고, 해당 컴포넌트의 신뢰성을 보장하기 위해 테스트하는 데 상당한 비용이 발생할 수 있습니다. 이러한 추가 비용은 재사용을 통한 전체 개발 비용 절감이 예상보다 적을 수 있음을 의미합니다.

소프트웨어 재사용 단점	설명
유지 보수 비용 증가 (Increased maintenance costs)	재사용된 소프트웨어 시스템이나 컴포넌트의 소스 코드가 제공되지 않는 경우, 시스템의 재사용된 요소들이 시스템 변경과 점점 더 호환되지 않게 되므로 유지 보수 비용이 더 높아질 수 있습니다.
도구 지원 부족 (Lack of tool support)	일부 소프트웨어 도구는 재사용을 염두에 두고 개발되지 않아, 컴포넌트 라이브러리 시스템과 통합하기 어렵거나 불가능할 수 있습니다. 이러한 도구들은 재사용을 고려하지 않는 소프트웨어 프로세스를 가정할 수 있으며, 특히 임베디드 시스템 엔지니어링을 지원하는 도구에서 이러한 문제가 발생할 가능성이 큽니다. 객체 지향 개발 도구에서는 이러한 문제가 덜합니다.
"내가 만들지 않은 것"에 대한 거부감 (Not-invented-here syndrome)	일부 소프트웨어 엔지니어는 컴포넌트를 다시 작성하려는 경향이 있습니다. 이는 그들이 기존 컴포넌트를 개선할 수 있다고 믿기 때문이기도 하고, 원래의 소프트웨어를 작성하는 것이 다른 사람의 소프트웨어를 재사용하는 것보다 더 도전적인 작업으로 여겨지기 때문이기도 합니다.
컴포넌트 라이브러리 생성, 유지 및 사용 (Creating, maintaining, and using a component library)	재사용 가능한 컴포넌트 라이브러리를 구축하고, 소프트웨어 개발자가 이 라이브러리를 사용할 수 있도록 하는 것은 비용이 많이 들 수 있습니다. 개발 프로세스는 라이브러리 사용을 보장하기 위해 적절히 조정되어야 합니다.
재사용 가능한 컴포넌트 찾기, 이해 및 적용 (Finding, understanding, and adapting reusable components)	소프트웨어 컴포넌트는 라이브러리에서 찾아내어 이해하고, 때로는 새로운 환경에서 작동하도록 적응시켜야 합니다. 엔지니어는 컴포넌트 검색을 일반적인 개발 프로세스의 일부로 포함하기 전에 라이브러리에서 해당 컴포넌트를 찾을 수 있다는 확신을 가져야 합니다.

 

소프트웨어 개발 프로세스는 재사용을 고려하도록 조정되어야 합니다. 특히, 시스템의 요구 사항이 사용 가능한 재사용 소프트웨어를 반영하도록 수정되는 요구 사항 정제 단계가 필요합니다. 시스템의 설계 및 구현 단계에서도 재사용할 수 있는 후보 컴포넌트를 찾고 평가하는 명시적인 활동이 포함될 수 있습니다.

 

소프트웨어 재사용은 조직 전체의 재사용 프로그램의 일환으로 계획될 때 가장 효과적입니다. 재사용 프로그램에는 재사용 가능한 자산의 생성과 이러한 자산을 새로운 소프트웨어에 통합하기 위해 개발 프로세스를 조정하는 것이 포함됩니다. 

 

16.1 재사용 랜드스케이프 (The Reuse Landscape)

소프트웨어 재사용을 지원하기 기술들은 많이 개발되었습니다. 이러한 기술들은 동일한 응용 도메인 내 시스템이 유사하며 재사용 가능성이 있다는 사실, 단순한 기능에서 전체 응용 프로그램에 이르기까지 다양한 수준에서 재사용이 가능하다는 사실, 그리고 재사용 가능한 컴포넌트에 대한 표준이 재사용을 촉진한다는 사실을 활용합니다. 다음 그림 16.3은 재사용을 지원하는 기술들의 나열한 것입니다. 

그림 16.3 재사용 기술 나열

 

이러한 재사용 기술 중 어떤 것이 특정 상황에서 가장 적합한지 판단하는 것이 중요합니다. 이는 개발 중인 시스템의 요구 사항, 사용 가능한 기술 및 재사용 자산, 그리고 개발 팀의 전문 지식에 따라 다릅니다. 재사용을 계획할 때 고려해야 할 주요 요소는 다음과 같습니다:

1. 소프트웨어 개발 일정: 소프트웨어가 신속하게 개발되어야 하는 경우, 개별 컴포넌트보다는 기성 제품을 재사용하는 것이 좋습니다. 이러한 대규모 재사용 자산은 요구 사항과의 적합성이 완벽하지 않을 수 있지만, 개발이 필요하지 않은 양을 최소화합니다.
2. 소프트웨어의 예상 수명: 장기 수명 시스템을 개발하는 경우, 시스템의 유지보수성을 중점적으로 고려해야 합니다. 재사용의 즉각적인 이점뿐만 아니라 장기적인 영향을 고려해야 합니다. 시스템 수명 동안, 새로운 요구 사항에 맞게 시스템을 조정해야 하며, 이는 시스템의 일부를 변경해야 함을 의미합니다. 소스 코드에 접근할 수 없는 경우, 기성 부품 및 외부 공급업체로부터의 시스템을 피하는 것이 좋습니다. 공급업체는 재사용된 소프트웨어에 대한 지원을 계속할 수 없을 수도 있습니다.
3. 개발 팀의 배경, 기술 및 경험: 모든 재사용 기술은 상당히 복잡하며, 이를 효과적으로 이해하고 사용하는 데 상당한 시간이 필요합니다. 따라서 개발 팀이 특정 분야에서 기술을 보유하고 있는 경우, 그 분야에 초점을 맞추는 것이 좋습니다.
4. 소프트웨어의 중요도 및 비기능 요구 사항: 외부 규제 기관에서 인증해야 하는 중요한 시스템의 경우, 시스템에 대한 신뢰성 사례를 만들어야 할 수도 있습니다. 소프트웨어 소스 코드에 접근할 수 없는 경우, 이를 수행하는 것이 어렵습니다. 소프트웨어에 엄격한 성능 요구 사항이 있는 경우, 시스템의 재사용을 기반으로 하는 전략을 사용하는 것이 불가능할 수 있습니다. 이러한 시스템은 종종 상대적으로 비효율적인 코드를 생성합니다.
5. 응용 도메인: 제조 및 의료 정보 시스템과 같은 일부 응용 도메인에서는 로컬 상황에 맞게 구성할 수 있는 여러 가지 일반 제품이 있습니다. 그러한 도메인에서 작업하는 경우, 항상 이를 옵션으로 고려해야 합니다.
6. 시스템이 실행될 플랫폼: .NET과 같은 일부 컴포넌트 모델은 Microsoft 플랫폼에만 특화되어 있습니다. 마찬가지로, 일반 응용 시스템은 플랫폼에 특화되어 있을 수 있으며, 시스템이 동일한 플랫폼으로 설계된 경우에만 재사용할 수 있습니다.

다음 표는 소프트웨어 재사용을 지원하는 방법론들을 정리하였습니다.

방법론	설명
아키텍처 패턴 (Architectural patterns)	일반적인 응용 시스템 유형을 지원하는 표준 소프트웨어 아키텍처를 애플리케이션의 기반으로 사용합니다.
설계 패턴 (Design patterns)	여러 애플리케이션에서 발생하는 일반적인 추상화를 디자인 패턴으로 표현하여 추상 및 구체적 객체와 상호작용을 보여줍니다.
컴포넌트 기반 개발 (Component-based development)	컴포넌트 모델 표준을 준수하는 객체 집합을 통합하여 시스템을 개발합니다.
어플리케이션 프레임워크 (Application Framework)	추상 및 구체적 클래스의 모음을 적용하고 확장하여 애플리케이션 시스템을 생성합니다.
레거시 시스템 래핑 (Legacy system wrapping)	레거시 시스템을 "래핑"하여 인터페이스 세트를 정의하고 이러한 인터페이스를 통해 레거시 시스템에 접근합니다.
서비스 지향 시스템 (Service-oriented systems)	외부에서 제공될 수 있는 공유 서비스를 연결하여 시스템을 개발합니다.
소프트웨어 제품 라인 (Software product lines)	공통 아키텍처를 중심으로 응용 프로그램 유형을 일반화하여 다른 고객에게 맞게 적응할 수 있도록 합니다.
COTS 제품 재사용 (COTS product reuse)	기존 어플리케이션 시스템을 구성하고 통합하여 시스템을 개발합니다.
ERP 시스템 (ERP systems)	일반적인 비즈니스 기능과 규칙을 캡슐화한 대규모 시스템을 조직에 맞게 구성합니다.
Configurable vertical applications	특정 시스템 고객의 요구세 맞게 구성될 수 있도록 설계된 일반 시스템입니다.
프로그램 라이브러리 (Program libraries)	자주 사용되는 추상화를 구현하는 클래스 함수 라이브러리가 재사용을 위해 제공됩니다.
Model-driven engineering	소프트웨어를 도메인 모델 및 구현 독립 모델로 표현하고, 이러한 모델에서 코드를 생성합니다.
프로그램 생성기 (Program generators)	생성기 시스템은 특정 어플리케이션 유형에 대한 지식을 내장하고 있으며, 사용자 제공 시스템 모델에서 해당 도메인의 시스템을 생성하는데 사용됩니다.
Aspect-oriented software development	공유 컴포넌트가 프로그램이 컴파일될 때 어플리케이션의 다양한 위치에 추가됩니다.

 

그림 16.3에서 보는 바와 같이 사용 가능한 재사용 기술의 범위는 대부분의 상황에서 어느 정도 소프트웨어 재사용이 가능하다는 것을 알 수 있습니다. 하지만 재사용이 이루어질지 여부는 종종 기술적 문제보다는 관리적 문제입니다. 관리자는 재사용 가능한 컴포넌트를 관리하기 위해 요구사항 변경이나 신규 요구사항 반영 협의를 수용하지 않을 수 있습니다. 반면, 신규 소프트웨어 개발의 위험이 더 클 수 있지만, 일부 관리자는 재사용에 의해 알려진 위험보다 신규 개발에 의한 알려지지 않은 위험을 더 선호할 수 있습니다.

 

16.2 어플리케이션 프레임워크 (Application Frameworks)

소프트웨어 재사용 기반의 개발 전략 중 하나인 어플리케이션 프레임워크(Application Frameworks)는 소프트웨어 개발 과정에서 재사용을 촉진하기 위한 중요한 방법론입니다. 객체 지향 개발이 처음 도입될 때, 객체를 여러 시스템에서 재사용할 수 있다는 점이 주요 이점으로 제시되었지만, 경험에 따르면 객체들은 종종 너무 작거나 특정 애플리케이션에 특화되어 있어 다른 시스템에서 재사용하기 어렵다는 문제가 있었습니다. 이러한 문제를 해결하기 위해 객체 지향 재사용을 지원하는 더 큰 규모의 추상화 개념인 프레임워크가 등장하게 되었습니다.

 

프레임워크는 이름 그대로 특정 애플리케이션이나 하위 시스템을 생성하기 위해 확장되는 일반적인 구조입니다. Schmidt 등(2004)은 프레임워크를 “관련된 응용 프로그램 계열을 위한 재사용 가능한 아키텍처를 제공하기 위해 협력하는 소프트웨어 아티팩트(예: 클래스, 객체 및 컴포넌트)의 통합된 집합”으로 정의하고 있습니다.

 

프레임워크는 유사한 유형의 모든 애플리케이션에서 사용될 가능성이 높은 일반적인 기능들을 지원합니다. 예를 들어, 사용자 인터페이스 프레임워크는 인터페이스 이벤트 처리를 지원하고, 위젯 세트를 포함하여 디스플레이를 구성하는 데 사용할 수 있도록 지원합니다. 개발자는 이를 바탕으로 특정 애플리케이션에 맞는 기능을 추가하여 특수화할 수 있습니다.

 

프레임워크는 시스템의 스켈레톤 아키텍처와 특정 클래스의 재사용을 모두 제공함으로써 설계 재사용을 지원합니다. 이러한 아키텍처는 객체 클래스와 그 상호작용에 의해 정의되며, 클래스는 직접 재사용되거나 상속과 같은 기능을 통해 확장될 수 있습니다.

 

프레임워크는 객체 지향 프로그래밍 언어에서 구체적이거나 추상적인 객체 클래스의 집합으로 구현되므로 언어에 특화되어 있습니다. 예를 들어, Java, C#, C++뿐만 아니라 Ruby와 Python과 같은 동적 언어에서도 프레임워크가 사용될 수 있습니다. 실제로, 프레임워크는 여러 다른 프레임워크를 통합할 수 있으며, 각 프레임워크는 애플리케이션의 일부를 개발하는 데 사용됩니다. 프레임워크를 사용하여 전체 애플리케이션을 만들거나, 그래픽 사용자 인터페이스(GUI)와 같은 애플리케이션의 일부를 구현할 수 있습니다.

 

Fayad와 Schmidt(1997)는 프레임워크를 다음과 같은 세 가지로 분류합니다:

 

1. 시스템 인프라 프레임워크: 통신, 사용자 인터페이스, 컴파일러 등과 같은 시스템 인프라를 개발하는 데 사용됩니다.

2. 미들웨어 통합 프레임워크: 컴포넌트간의 통신과 정보 교환을 지원하는 표준 및 관련 객체 클래스 집합으로 구성됩니다. 예를 들어, Microsoft의 .NET과 Enterprise Java Beans(EJB)가 이에 해당합니다.

3. 엔터프라이즈 애플리케이션 프레임워크: 통신 또는 금융 시스템과 같은 특정 애플리케이션 도메인에 초점을 맞추며, 애플리케이션 도메인 지식을 내장하고 최종 사용자 애플리케이션 개발을 지원합니다.

 

웹 애플리케이션 프레임워크(Web Application Frameworks, WAFs)는 최근에 등장한 매우 중요한 유형의 프레임워크로, 동적 웹사이트 구축을 지원하는 WAFs는 이제 널리 사용되고 있습니다. WAF의 아키텍처는 일반적으로 모델-뷰-컨트롤러(Model-View-Controller, MVC) 복합 패턴(Gamma 등, 1995)을 기반으로 합니다. MVC 패턴은 원래 1980년대에 GUI 설계를 위한 접근 방식으로 제안되었으며, 객체의 여러 프레젠테이션과 각 프레젠테이션과의 상호 작용 스타일을 별도로 허용하는 방식입니다. 이 패턴은 애플리케이션 상태를 사용자 인터페이스에서 분리하여 다양한 방식으로 데이터를 표시하고 각 프레젠테이션과의 상호 작용을 허용합니다. 프레젠테이션 중 하나를 통해 데이터가 수정되면 시스템 모델이 변경되고 각 뷰와 연결된 컨트롤러가 프레젠테이션을 업데이트합니다.

그림 16.5 MVC 모델 패턴 개요

 

프레임워크는 종종 디자인 패턴을 구현한 것으로, 예를 들어 MVC 프레임워크에는 옵저버 패턴, 전략 패턴, 복합 패턴 및 다른 여러 패턴이 포함됩니다(Gamma 등, 1995). 패턴의 일반적인 특성과 추상 및 구체 클래스의 사용은 확장성을 가능하게 합니다. 패턴이 없다면 프레임워크는 거의 무용지물이 될 것입니다.

 

웹 애플리케이션 프레임워크를 예를 들어보면 일반적으로 특정 애플리케이션 기능을 지원하는 하나 이상의 특화된 프레임워크를 포함합니다. 각 프레임워크는 약간 다른 기능을 포함하지만, 대부분의 웹 애플리케이션 프레임워크는 다음과 같은 기능을 지원합니다:

1. 보안: WAFs는 사용자 인증(로그인) 및 접근 제어를 구현하는 데 도움이 되는 클래스를 포함하여 사용자가 시스템에서 허용된 기능에만 접근할 수 있도록 보장합니다.
2. 동적 웹 페이지: WAFs는 웹 페이지 템플릿을 정의하고 시스템 데이터베이스에서 특정 데이터를 동적으로 채우는 데 도움이 되는 클래스를 제공합니다.
3. 데이터베이스 지원: 프레임워크는 일반적으로 데이터베이스를 포함하지 않지만, MySQL과 같은 별도의 데이터베이스를 사용할 것으로 가정합니다. 프레임워크는 다양한 데이터베이스에 대한 추상 인터페이스를 제공하는 클래스를 포함할 수 있습니다.
4. 세션 관리: 사용자가 시스템과 상호 작용하는 동안의 세션을 생성하고 관리하는 클래스는 보통 WAF의 일부입니다.
5. 사용자 상호작용: 대부분의 웹 프레임워크는 이제 AJAX 지원을 제공하여 더 상호작용적인 웹 페이지를 만들 수 있습니다(Holdener, 2008).

프레임워크를 확장하기 위해서는 프레임워크 코드를 변경하지 않고, 추상 클래스에서 연산을 상속받는 구체적인 클래스를 추가합니다. 프레임워크를 활용한 애플리케이션은 추가 재사용을 위한 기초가 될 수 있으며, 소프트웨어 제품군 또는 애플리케이션 패밀리를 생성하는 데 사용될 수 있습니다.

 

그러나 프레임워크는 도입 비용이 높고, 사용법을 익히는 데 몇 달이 걸릴 수 있으며, 디버깅이 어려울 수 있습니다. 이는 재사용 가능한 소프트웨어의 일반적인 문제로, 개발자가 프레임워크의 상호작용을 완전히 이해하지 못할 경우 디버깅이 어려워질 수 있습니다.

 

 

16.3 소프트웨어 제품라인 (Software Product Line)

소프트웨어 재사용의 가장 효과적인 접근 방식 중 하나는 소프트웨어 제품 라인(Software Product Lines) 또는 애플리케이션 패밀리(Application Families)를 만드는 것입니다. 소프트웨어 제품 라인은 공통 아키텍처와 공유된 컴포넌트를 가진 일련의 애플리케이션으로, 각각의 애플리케이션은 서로 다른 요구 사항을 반영하여 특화됩니다. 이 핵심 시스템은 다양한 시스템 고객의 요구에 맞추어 구성 및 조정되도록 설계됩니다. 이를 위해 일부 컴포넌트를 구성하거나, 추가적인 컴포넌트를 구현하고, 새로운 요구 사항을 반영하기 위해 기존의 컴폰너트를 수정할 수 있습니다.

 

제네릭 버전의 애플리케이션을 적응시켜 애플리케이션을 개발하면 애플리케이션 코드의 상당 부분이 재사용됩니다. 또한, 애플리케이션 경험은 종종 다른 시스템으로 이전될 수 있어 소프트웨어 엔지니어가 새로운 개발 팀에 합류할 때 학습 과정이 단축됩니다. 테스트 또한 단순화되어 애플리케이션 개발 시간을 단축할 수 있습니다.

 

소프트웨어 제품 라인은 기존 애플리케이션에서 발전하는 경우가 많습니다. 이는 조직이 애플리케이션을 개발하고, 유사한 시스템이 필요할 때 새로운 애플리케이션에서 이 코드를 비공식적으로 재사용하면서 발생합니다. 그러나 변화는 애플리케이션 구조를 손상시키기 때문에 새로운 인스턴스를 개발할수록 새로운 버전을 만드는 것이 점점 더 어려워집니다. 따라서, 제네릭 제품 라인을 설계하자는 결정이 내려질 수 있습니다. 이 과정에서는 제품 인스턴스의 공통 기능을 식별하고 이를 기반 애플리케이션에 포함시켜 향후 개발에 사용하도록 합니다. 이 기반 애플리케이션은 재사용과 재구성을 용이하게 하도록 의도적으로 구조화됩니다.

 

애플리케이션 프레임워크와 소프트웨어 제품 라인은 공통 아키텍처와 컴포넌트를 지원하며, 특정 시스템 버전을 생성하기 위해 새로운 개발이 필요하다는 점에서 많은 공통점을 가지고 있습니다. 그러나 이 접근 방식들 사이에는 다음과 같은 주요 차이점이 있습니다:

1. 애플리케이션 프레임워크는 상속 및 다형성과 같은 객체 지향 기능에 의존하여 프레임워크에 대한 확장을 구현합니다.
   일반적으로 프레임워크 코드는 수정되지 않으며, 수정 가능한 범위는 프레임워크에서 허용되는 것에 한정됩니다. 소프트웨어 제품 라인은 반드시 객체 지향 접근 방식을 통해 생성되지 않을 수 있습니다. 애플리케이션 컴포넌트는 변경, 삭제, 또는 재작성될 수 있으며, 원칙적으로는 변경에 제한이 없습니다.
2. 애플리케이션 프레임워크는 주로 기술적인 지원을 제공하는 데 중점을 둡니다.
   예를 들어, 웹 기반 애플리케이션을 생성하는 애플리케이션 프레임워크가 있습니다. 소프트웨어 제품 라인은 일반적으로 세부적인 도메인 및 플랫폼 정보를 내포하고 있습니다. 예를 들어, 웹 기반 애플리케이션을 위한 건강 기록 관리와 관련된 소프트웨어 제품 라인이 있을 수 있습니다.
3. 소프트웨어 제품 라인은 장치(device)를 제어하는 임베디드 소프트웨어로 구성되는 경우가 많습니다.
   예를 들어, 프린터 제품군을 위한 소프트웨어 제품 라인이 있을 수 있습니다. 이 제품 라인은 하드웨어 인터페이스 지원을 제공해야 합니다. 애플리케이션 프레임워크는 일반적으로 소프트웨어 지향적이며, 하드웨어 인터페이스 지원을 제공하는 경우는 드뭅니다.
4. 소프트웨어 제품 라인은 동일한 조직에서 소유한 관련 애플리케이션 패밀리로 구성됩니다.
   새로운 애플리케이션을 생성할 때는 일반적으로 제네릭 코어 애플리케이션이 아니라 가장 유사한 애플리케이션 패밀리 멤버가 시작점이 됩니다.

통상 소프트웨어 제품 라인을 개발하고자 할 떄, 먼저 도메인 특화 컴포넌트를 사용하여 프레임워크를 확장하여 제품 라인의 코어를 생성한 다음, 시스템의 다양한 고객 버전을 생성하는 두 번째 개발 단계를 거칩니다.

다음은 제가 작성한 소프트웨어 제품 라인에 대한 글입니다. 한번 참고 해 보는 것도 좋을 듯 합니다.

 

Software Product Line (SPL)

 

소프트웨어 제품 라인은 다양한 특수화 유형으로 개발될 수 있습니다:

 

1. 플랫폼 특수화: 애플리케이션의 버전이 다른 플랫폼에 맞게 개발됩니다. 예를 들어, Windows, Mac OS, Linux 플랫폼에 대한 버전이 존재할 수 있습니다. 이 경우, 애플리케이션의 기능은 일반적으로 변경되지 않으며, 하드웨어 및 운영 체제와의 인터페이스를 처리하는 컴포넌트만 수정됩니다.

2. 환경 특수화: 특정 운영 환경과 주변 장치를 처리하기 위해 애플리케이션의 버전이 생성됩니다. 예를 들어, 응급 서비스 시스템의 경우, 차량 통신 시스템에 따라 다른 버전이 존재할 수 있습니다. 이 경우, 시스템 컴포넌트는 사용된 통신 장비의 기능을 반영하도록 변경됩니다.

3. 기능 특수화: 서로 다른 요구 사항을 가진 특정 고객을 위해 애플리케이션의 버전이 생성됩니다. 예를 들어, 도서관 자동화 시스템은 공공 도서관, 참고 도서관, 또는 대학 도서관에서 사용되는지에 따라 수정될 수 있습니다. 이 경우, 기능을 구현하는 컴포넌트가 수정되거나 시스템에 새로운 컴포넌트가 추가될 수 있습니다.

4. 프로세스 특수화: 시스템이 특정 비즈니스 프로세스에 맞추어 조정됩니다. 예를 들어, 주문 시스템이 한 회사에서는 중앙 집중식 주문 프로세스를 처리하도록, 다른 회사에서는 분산된 프로세스를 처리하도록 조정될 수 있습니다.

 

소프트웨어 제품 라인의 아키텍처는 일반적으로 애플리케이션 특화 아키텍처 스타일 또는 패턴을 반영합니다. 예를 들어, 그림 16.7은 긴급 서비스 차량 디스패칭을 처리하기 위해 설계된 제품 라인 시스템을 생각해 볼 수 있습니다. 이 시스템은 자원 관리 아키텍처의 한 예로, 차량 디스패칭 시스템 제품 라인에서 각 수준의 컴포넌트는 특정 모듈로 구성됩니다. (그림 16.8)

그림 16.7 자원 할당 시스템 아키텍처

그림 16.8 차량 디스패처 시스템의 제품라인 아키텍처

 

소프트웨어 제품 라인을 확장하여 새로운 애플리케이션을 생성하는 과정은 몇 가지 단계로 구성됩니다(그림 16.9):

그림 16.9 제품 인스턴스 개발

 

1. 이해관계자 요구 사항 수집: 일반적인 요구 사항 엔지니어링 프로세스로 시작할 수 있지만, 이미 시스템이 존재하기 때문에 시스템을 시연하고 이해관계자가 이를 실험하게 하여 제공되는 기능의 수정으로서 그들의 요구 사항을 표현하도록 해야 합니다.

2. 기존 시스템 중 요구 사항에 가장 적합한 시스템 선택: 제품 라인의 새로운 멤버를 생성할 때 가장 가까운 제품 인스턴스에서 시작할 수 있습니다. 요구 사항을 분석하고, 수정할 가장 적합한 패밀리 멤버를 선택합니다.

3. 요구 사항 재협상: 필요한 변경 사항이 더 자세히 밝혀지고 프로젝트가 계획됨에 따라 변경이 필요한 요구 사항을 최소화하기 위해 요구 사항을 재협상할 수 있습니다.

4. 기존 시스템 적응: 기존 시스템을 위한 새로운 모듈이 개발되고, 새로운 요구 사항을 충족하기 위해 기존 시스템 모듈이 적응됩니다.

5. 새로운 패밀리 멤버 제공: 제품 라인의 새로운 인스턴스가 고객에게 제공됩니다. 이 단계에서, 향후 시스템 개발의 기초로 사용할 수 있도록 주요 기능을 문서화해야 합니다.

 

제품 라인의 새로운 멤버를 생성할 때, 제네릭 애플리케이션을 가능한 많이 재사용하고 이해관계자의 세부 요구 사항을 충족시키는 사이에서 절충안을 찾아야 할 수 있습니다. 요구 사항이 더 세밀할수록 기존 컴포넌트가 이러한 요구 사항을 충족할 가능성은 낮아집니다. 그러나 이해관계자가 유연하게 대처하고 필요한 시스템 수정을 제한한다면, 일반적으로 시스템을 더 빨리, 그리고 더 낮은 비용으로 제공할 수 있습니다.

그림 16.10 배포시점 구성

 

소프트웨어 제품 라인은 재구성을 위해 설계되며, 이 재구성은 시스템의 컴포넌트를 추가하거나 제거하고, 시스템 컴포넌트의 매개변수 및 제약 조건을 정의하며, 비즈니스 프로세스에 대한 지식을 포함할 수 있습니다. 이 구성은 개발 프로세스의 다양한 단계에서 발생할 수 있습니다:

 

1. 설계 시점 구성: 소프트웨어를 개발하는 조직이 공통 제품 라인 코어를 수정하여 고객을 위한 새로운 시스템을 생성합니다.

2. 배포 시점 구성: 일반 시스템은 고객이나 고객과 협력하는 컨설턴트가 구성할 수 있도록 설계됩니다. 고객의 특정 요구 사항과 시스템의 운영 환경에 대한 지식이 구성 파일 세트에 내장되어 있으며, 이 파일은 배포 시점에 시스템이 구성되도록 합니다(그림 16.10 참조).

 

16.4 COTS 제품 재사용

상용 기성품 소프트웨어(COTS, Commercial-Off-The-Shelf)는 시스템의 소스 코드를 변경하지 않고도 다양한 고객의 요구에 맞게 조정할 수 있는 소프트웨어 시스템을 의미합니다. 거의 모든 데스크탑 소프트웨어와 다양한 서버 제품들이 COTS 소프트웨어에 해당합니다. 이러한 소프트웨어는 일반적인 용도로 설계되었기 때문에 많은 기능과 특징을 포함하고 있어, 다양한 환경에서 그리고 다양한 애플리케이션의 일부로 재사용될 가능성이 큽니다. Torchiano와 Morisio(2004)는 오픈 소스 제품도 종종 COTS 제품으로 사용된다는 사실을 발견했습니다. 즉, 오픈 소스 시스템을 변경 없이, 소스 코드를 보지 않고 사용하는 경우가 많습니다.

 

COTS 제품은 시스템의 기능을 특정 고객의 요구에 맞게 조정할 수 있는 내장된 구성 메커니즘을 통해 조정됩니다. 예를 들어, 병원 환자 기록 시스템에서는 다양한 유형의 환자를 위해 별도의 입력 양식과 출력 보고서를 정의할 수 있습니다. 다른 구성 기능들은 시스템이 플러그인을 받아들여 기능을 확장하거나, 사용자의 입력이 유효한지 확인하는 등의 역할을 할 수 있습니다.

 

이러한 COTS 제품 재사용은 맞춤형 소프트웨어 개발에 비해 상당한 이점을 제공합니다:

 

1. 다른 유형의 재사용과 마찬가지로, 신뢰할 수 있는 시스템을 더 빠르게 배포할 수 있습니다.

2. 애플리케이션이 제공하는 기능을 사전에 확인할 수 있어, 이들이 적합한지 판단하기가 더 쉬워집니다. 다른 회사들이 이미 이러한 시스템을 사용하고 있을 수 있으며, 그로부터 경험을 얻을 수 있습니다.

3. 기존 소프트웨어를 사용함으로써 일부 개발 리스크를 피할 수 있습니다. 그러나 이 접근 방식에도 고유한 위험이 존재합니다.

4. 기업은 IT 시스템 개발에 많은 자원을 할애하지 않고도 핵심 활동에 집중할 수 있습니다.

5. 운영 플랫폼이 발전함에 따라 기술 업데이트가 간소화될 수 있으며, 이는 고객이 아닌 COTS 제품 공급업체의 책임입니다.

 

물론, 이러한 소프트웨어 엔지니어링 접근 방식에도 문제가 있습니다:

 

1. 요구 사항이 COTS 제품의 기능과 운영 모드에 맞게 조정되어야 하며, 이는 기존 비즈니스 프로세스에 혼란을 초래할 수 있습니다.

2. COTS 제품은 변경이 불가능한 가정에 기반을 두고 있을 수 있으며, 고객은 이러한 가정에 맞춰 비즈니스를 조정해야 할 수 있습니다.

3. 기업에 적합한 COTS 시스템을 선택하는 것은 어려운 과정이 될 수 있습니다. 많은 COTS 제품이 잘 문서화되지 않았기 때문에, 잘못된 선택을 하면 시스템을 원하는 대로 작동시킬 수 없게 되어 큰 문제를 야기할 수 있습니다.

4. 시스템 개발을 지원할 수 있는 현지 전문가가 부족할 수 있습니다. 따라서 고객은 벤더와 외부 컨설턴트에게 개발 조언을 의존해야 하며, 이 조언은 고객의 실제 요구보다는 제품과 서비스를 판매하는 데 중점을 둔 편향된 조언일 수 있습니다.

5. COTS 제품 공급업체가 시스템 지원 및 발전을 통제합니다. 그들이 사업을 중단하거나 인수되거나 고객에게 어려움을 초래할 수 있는 변경을 가할 수도 있습니다.

 

COTS 제품 재사용에는 두 가지 유형이 있습니다. 바로 COTS-솔루션 시스템과 COTS-통합 시스템입니다. COTS-솔루션 시스템은 단일 벤더의 일반 애플리케이션을 고객 요구 사항에 맞게 구성하는 것이고, COTS-통합 시스템은 두 개 이상의 COTS 시스템을 통합하여 애플리케이션 시스템을 만드는 것입니다. 다음 표는 이러한 접근 방식들 간의 차이점을 요약하고 있습니다.

COTS-solution systems	COTS-integrated systems
고객이 필요한 기능을 제공하는 단일 제품	커스터마이징 된 기능을 제공하기 위해 통합된 여러 이기종 시스템 제품
일반적인 솔루션과 표준화된 프로세스를 중심으로 구성됨	고객 프로세스에 맞춘 유연한 솔루션이 개발될 수 있음
개발 초점이 시스템 구성을 중심으로 함	개발 초점이 시스템 통합에 맞춰짐
시스템 유지보수는 시스템 공급업체의 책임	시스템 유지보수는 시스템 소유자의 책임
시스템 플랫폼은 시스템 공급업체가 제공	시스템 플랫폼은 시스템 소유자가 제공

 

16.4.1 COTS 솔루션 시스템

COTS 솔루션 시스템은 특정 비즈니스 유형, 비즈니스 활동 또는 전체 비즈니스 기업을 지원하도록 설계된 일반적인 응용 시스템입니다. 예를 들어, COTS 솔루션 시스템은 치과 의사를 위해 제작되어 예약 관리, 치과 기록, 환자 회상 등을 처리할 수 있습니다. 더 큰 규모에서는 ERP(Enterprise Resource Planning) 시스템이 대규모 회사의 제조, 주문 및 고객 관계 관리 활동을 모두 지원할 수 있습니다.

 

비즈니스 기능을 지원하는 도메인 특화 COTS 솔루션 시스템(예: 문서 관리 시스템)은 다양한 잠재 사용자에게 요구될 가능성이 있는 기능을 제공합니다. 그러나 이러한 시스템은 사용자 작업 방식에 대한 내장된 가정을 포함하고 있어 특정 상황에서 문제가 발생할 수 있습니다. 예를 들어, 대학에서 학생 등록을 지원하는 시스템은 학생들이 한 대학에서 하나의 학위에 등록한다고 가정할 수 있습니다. 그러나 대학들이 공동 학위를 제공하는 경우, 이를 시스템에서 나타내기가 사실상 불가능할 수 있습니다.

 

SAP와 BEA에서 제공하는 ERP 시스템과 같은 대규모 통합 시스템은 주문 및 송장 처리, 재고 관리, 제조 일정 관리와 같은 비즈니스 관행을 지원하도록 설계되었습니다. 이러한 시스템의 구성 프로세스는 고객의 비즈니스 및 비즈니스 프로세스에 대한 자세한 정보를 수집하고 이를 구성 데이터베이스에 내장하는 과정을 포함합니다. 이 과정은 종종 구성 표기법 및 도구에 대한 자세한 지식이 필요하며, 일반적으로 시스템 고객과 함께 일하는 컨설턴트에 의해 수행됩니다.

 

일반적인 ERP 시스템은 여러 모듈로 구성되어 있으며, 이러한 모듈을 구성하여 고객을 위한 시스템을 만들 수 있습니다. 구성 프로세스는 포함할 모듈을 선택하고, 개별 모듈을 구성하며, 비즈니스 프로세스와 비즈니스 규칙을 정의하고, 시스템 데이터베이스의 구조와 조직을 정의하는 것을 포함합니다. [그림 16.12]는 다양한 비즈니스 기능을 지원하는 ERP 시스템의 전체 아키텍처 모델을 보여줍니다.

그림 16.12 ERP 시스템 아키텍처

 

이 아키텍처의 주요 특징은 다음과 같습니다:

 

1. 다양한 비즈니스 기능을 지원하는 여러 모듈이 포함됩니다. 이들은 비즈니스의 전체 부서나 부문을 지원할 수 있는 대규모 모듈입니다. [그림 16.12]에 표시된 예에서 시스템에 포함된 모듈은 구매 지원 모듈, 공급망 관리 지원 모듈, 물류 지원 모듈, 고객 관계 관리(CRM) 모듈입니다.

2. 각 모듈과 관련된 정의된 비즈니스 프로세스 집합이 있으며, 이는 해당 모듈의 활동과 관련이 있습니다. 예를 들어, 주문이 생성되고 승인되는 방법을 정의하는 주문 처리 프로세스 정의가 있을 수 있습니다.

3. 모든 관련 비즈니스 기능에 대한 정보를 유지 관리하는 공통 데이터베이스가 포함됩니다. 이는 비즈니스의 다른 부분에서 고객 세부 정보와 같은 정보를 복제할 필요가 없음을 의미합니다.

4. 데이터베이스의 모든 데이터에 적용되는 일련의 비즈니스 규칙이 있습니다. 따라서 한 기능에서 데이터가 입력될 때 이러한 규칙은 다른 기능에서 요구하는 데이터와 일관되도록 보장해야 합니다. 예를 들어, 모든 경비 청구는 청구한 사람보다 상급자에 의해 승인되어야 한다는 비즈니스 규칙이 있을 수 있습니다.

 

ERP 시스템은 거의 모든 대기업에서 일부 또는 모든 기능을 지원하는 데 사용됩니다. 따라서 매우 널리 사용되는 소프트웨어 재사용 방식입니다. 그러나 이러한 재사용 접근 방식의 명백한 한계는 시스템 기능이 일반 코어의 기능으로 제한된다는 점입니다. 또한 회사의 프로세스와 운영은 시스템 구성 언어로 표현되어야 하며, 비즈니스 개념과 구성 언어에서 지원하는 개념 간에 불일치가 발생할 수 있습니다.

 

예를 들어, 대학에 판매된 ERP 시스템에서 ‘고객’의 개념을 정의하는 것이 큰 어려움을 초래했습니다. 그러나 대학에는 학생, 연구 기금 기관, 교육 자선 단체 등과 같이 여러 유형의 고객이 있으며, 각각의 특성이 다릅니다. 이들 중 어느 것도 상업적 고객(즉, 제품이나 서비스를 구매하는 개인 또는 기업)의 개념과 비교할 수 없습니다. 시스템에서 사용하는 비즈니스 모델과 시스템 구매자의 비즈니스 모델 간에 심각한 불일치가 발생하면 ERP 시스템이 구매자의 실제 요구를 충족하지 못할 가능성이 매우 높습니다(Scott, 1999).

 

도메인 특화 COTS 제품과 ERP 시스템 모두 설치되는 각 조직의 요구 사항에 맞게 조정하기 위해 광범위한 구성이 필요합니다. 이러한 구성은 다음을 포함할 수 있습니다:

 

1. 시스템에서 필요한 기능을 선택합니다(예: 포함할 모듈을 결정함).

2. 조직의 데이터가 시스템 데이터베이스에 어떻게 구조화될지 정의하는 데이터 모델을 설정합니다.

3. 해당 데이터에 적용되는 비즈니스 규칙을 정의합니다.

4. 외부 시스템과의 예상 상호작용을 정의합니다.

5. 시스템에서 생성된 입력 양식과 출력 보고서를 설계합니다.

6. 시스템에서 지원하는 기본 프로세스 모델에 따라 새로운 비즈니스 프로세스를 설계합니다.

7. 시스템이 기본 플랫폼에 배포되는 방식을 정의하는 매개 변수를 설정합니다.

 

구성 설정이 완료되면 COTS 솔루션 시스템은 테스트 준비가 완료됩니다. 시스템이 기존의 프로그래밍 언어를 사용하여 프로그래밍된 것이 아니라 구성된 경우, 테스트는 주요 문제가 될 수 있습니다. 이러한 시스템은 신뢰할 수 있는 플랫폼을 사용하여 구축되므로 명백한 시스템 오류와 충돌은 상대적으로 드뭅니다. 문제는 종종 미묘하며 운영 프로세스와 시스템 구성 간의 상호작용과 관련이 있을 수 있으며, 이는 시스템 테스트 과정에서 발견되지 않을 수 있습니다. 또한 JUnit과 같은 테스트 프레임워크에서 지원하는 자동화된 단위 테스트를 사용할 수 없습니다. 기본 시스템은 테스트 자동화를 지원할 가능성이 적으며, 시스템 테스트를 도출하는 데 사용할 수 있는 완전한 시스템 사양이 없을 수도 있습니다.

 

16.4.2 COTS 통합 시스템

COTS 통합 시스템은 두 개 이상의 COTS 제품 또는 때로는 레거시 응용 시스템을 포함하는 애플리케이션입니다. 하나의 COTS 시스템이 모든 요구를 충족하지 않거나 기존에 사용 중인 시스템과 새 COTS 제품을 통합하려는 경우에 이 접근 방식을 사용할 수 있습니다. COTS 제품은 정의된 API(응용 프로그램 인터페이스) 또는 서비스 인터페이스를 통해 상호 작용할 수 있습니다. 그렇지 않으면 한 시스템의 출력을 다른 시스템의 입력에 연결하거나 COTS 응용 프로그램이 사용하는 데이터베이스를 업데이트하는 방식으로 구성될 수 있습니다.

 

COTS 제품을 사용하여 시스템을 개발하려면 여러 가지 설계 선택을 해야 합니다:

 

1. 가장 적합한 기능을 제공하는 COTS 제품은 무엇입니까? 일반적으로 여러 COTS 제품이 제공되며, 다양한 방식으로 결합할 수 있습니다. COTS 제품에 대한 경험이 없다면 어떤 제품이 가장 적합한지 결정하기 어려울 수 있습니다.

2. 데이터는 어떻게 교환될 것입니까? 서로 다른 제품은 일반적으로 고유한 데이터 구조와 형식을 사용합니다. 이러한 표현을 서로 변환하는 어댑터를 작성해야 합니다. 이러한 어댑터는 COTS 제품과 함께 작동하는 런타임 시스템입니다.

3. 제품의 어떤 기능을 실제로 사용할 것인가? COTS 제품은 필요한 것보다 더 많은 기능을 포함할 수 있으며, 기능이 여러 제품에 걸쳐 중복될 수 있습니다. 어떤 제품의 어떤 기능이 요구 사항에 가장 적합한지 결정해야 합니다. 가능하다면 사용되지 않는 기능에 대한 접근을 차단해야 합니다. 이 기능은 시스템의 정상 작동을 방해할 수 있습니다.

 

다음 시나리오를 통해 COTS 통합을 설명하겠습니다. 대규모 조직은 직원들이 책상에서 주문할 수 있는 조달 시스템을 개발하려고 합니다. 이 시스템을 조직 전체에 도입함으로써 회사는 연간 500만 달러를 절약할 수 있을 것으로 추정합니다. 구매를 중앙 집중화함으로써 새로운 조달 시스템은 항상 최저가를 제공하는 공급업체로부터 주문이 이루어지도록 보장할 수 있으며, 주문과 관련된 문서 작업 비용을 줄일 수 있습니다. 이 시스템은 공급업체에서 제공되는 상품을 선택하고, 주문을 생성하고, 주문을 승인받고, 주문을 공급업체로 전송하고, 상품을 수령하고, 결제가 이루어져야 함을 확인하는 과정을 포함합니다.

 

이 회사는 중앙 조달 사무소에서 사용되는 레거시 주문 시스템을 보유하고 있습니다. 이 주문 처리 소프트웨어는 기존 송장 및 배송 시스템과 통합되어 있습니다. 새 주문 시스템을 만들기 위해 레거시 시스템은 웹 기반 전자 상거래 플랫폼 및 사용자와의 통신을 처리하는 이메일 시스템과 통합됩니다. [그림 16.13]에 표시된 것처럼, COTS를 사용하여 구축된 최종 조달 시스템의 구조가 설명됩니다.

그림 16.13 COTS 통합 조달 시스템

 

이 조달 시스템은 클라이언트-서버 기반이며, 클라이언트에서 표준 웹 브라우징 및 이메일 소프트웨어를 사용합니다. 서버에서는 전자 상거래 플랫폼이 어댑터를 통해 기존 주문 시스템과 통합되어야 합니다. 전자 상거래 시스템은 주문, 배송 확인 등의 자체 형식을 가지고 있으며, 이러한 형식은 주문 시스템에서 사용되는 형식으로 변환되어야 합니다. 전자 상거래 시스템은 사용자에게 알림을 보내기 위해 이메일 시스템을 사용하지만, 주문 시스템은 이를 위해 설계되지 않았습니다. 따라서, 주문 시스템의 알림을 이메일 메시지로 변환하는 또 다른 어댑터를 작성해야 합니다.

 

이러한 COTS 통합 접근 방식을 사용하면 수개월, 때로는 수년의 구현 노력을 절약하고, 시스템 개발 및 배포 시간을 크게 단축할 수 있습니다. 위에서 설명한 조달 시스템은 Java로 시스템을 개발하는 데 예상되는 3년이 아니라 9개월 만에 매우 큰 회사에서 구현되고 배포되었습니다.

 

COTS 통합은 서비스 지향 접근 방식을 사용하면 단순화될 수 있습니다. 본질적으로, 서비스 지향 접근 방식은 애플리케이션 시스템의 기능에 표준 서비스 인터페이스를 통해 접근할 수 있도록 하는 것입니다. 일부 애플리케이션은 서비스 인터페이스를 제공할 수 있지만, 때로는 이 서비스 인터페이스를 시스템 통합자가 구현해야 합니다. 본질적으로, 응용 프로그램을 숨기고 외부에서 볼 수 있는 서비스를 제공하는 래퍼를 프로그래밍해야 합니다. 이 접근 방식은 특히 새로운 애플리케이션 시스템과 통합해야 하는 레거시 시스템에 유용합니다. (그림 16.14 참조)

그림 16.14 어플리케이션 래핑

 

원칙적으로 COTS 제품 통합은 다른 컴포넌트를 통합하는 것과 동일합니다. 시스템 인터페이스를 이해하고 소프트웨어와의 통신에 독점적으로 사용해야 합니다. 특정 요구 사항을 신속한 개발 및 재사용과 맞바꾸어야 하며, COTS 시스템이 함께 작동할 수 있는 시스템 아키텍처를 설계해야 합니다.

 

그러나 이러한 제품이 자체적으로 대규모 시스템인 경우가 많고, 종종 별도의 독립형 시스템으로 판매되기 때문에 추가적인 문제가 발생할 수 있습니다. Boehm과 Abts는 네 가지 중요한 COTS 시스템 통합 문제에 대해 논의합니다:

 

1. 기능 및 성능에 대한 제어 부족 - 제품의 공개된 인터페이스는 필요한 기능을 제공할 수 있을 것처럼 보일 수 있지만, 이러한 기능이 제대로 구현되지 않았거나 성능이 떨어질 수 있습니다. 제품에는 특정 상황에서 사용을 방해하는 숨겨진 작업이 있을 수 있습니다. 이러한 문제를 해결하는 것이 COTS 제품 통합자에게는 우선순위일 수 있지만, 제품 공급자에게는 큰 관심사가 아닐 수 있습니다. 사용자는 COTS 제품을 재사용하려는 경우 문제에 대한 해결 방법을 찾아야 할 수도 있습니다.

2. COTS 시스템 상호 운용성 문제 - 각 제품은 자신이 어떻게 사용될 것인지에 대한 가정을 내포하고 있어 COTS 제품을 함께 작동시키는 것이 어려울 때가 있습니다. Garlan 등은 네 가지 COTS 제품을 통합하려고 시도한 경험을 보고하면서 이들 중 세 가지 제품이 이벤트 기반이었지만, 각각 다른 이벤트 모델을 사용하고 있었다고 언급했습니다. 각 시스템은 이벤트 큐에 대한 독점적인 접근을 가정했기 때문에 통합이 매우 어려웠습니다. 이 프로젝트는 원래 예상했던 것보다 5배 더 많은 노력이 필요했고, 예측했던 6개월이 아닌 2년으로 일정이 연장되었습니다. Garlan 등은 10년 후에 그들의 작업을 회고하면서, 그들이 발견한 통합 문제가 여전히 해결되지 않았다고 결론지었습니다. Torchiano와 Morisio는 일부 COTS 제품에서 표준 준수가 부족하여 통합이 예상보다 더 어려웠다고 밝혔습니다.

3. 시스템 진화에 대한 통제 불능 - COTS 제품 공급자는 시장 압력에 대응하여 시스템 변경에 대한 자체 결정을 내립니다. 특히 PC 제품의 경우, 새로운 버전이 자주 출시되며 이전 버전과 호환되지 않을 수 있습니다. 새로운 버전에는 원하지 않는 추가 기능이 있을 수 있으며, 이전 버전은 사용할 수 없거나 지원되지 않을 수 있습니다.

4. COTS 공급자로부터의 지원 - COTS 공급자로부터 제공되는 지원 수준은 크게 다를 수 있습니다. 시스템의 소스 코드와 상세 문서에 접근할 수 없기 때문에 문제가 발생했을 때 공급자의 지원은 매우 중요합니다. 공급자가 지원을 제공하겠다고 약속할 수 있지만, 시장 및 경제 상황의 변화로 인해 이 약속을 이행하기 어려울 수 있습니다. 예를 들어, COTS 시스템 공급자는 수요가 제한적이라는 이유로 제품을 중단하기로 결정할 수 있거나, 다른 회사에 인수되어 인수된 모든 제품을 지원하지 않으려 할 수 있습니다.

 

Boehm과 Abts는 많은 경우에 COTS 통합 시스템의 유지 관리 및 진화 비용이 더 클 수 있다고 판단합니다. 위의 모든 어려움은 시스템 생명 주기 동안 발생하며, 초기 개발에만 영향을 미치는 것이 아닙니다. 시스템 유지 관리를 담당하는 사람들이 원래의 시스템 개발자들과 더 멀어질수록, 통합된 COTS 제품과 관련된 실제 어려움이 발생할 가능성이 더 큽니다.