CBD(Component Based Development)

기존의 시스템 및 소프트웨어를 구성하고 있는 컴포넌트를 조립해서 하나의 새로운 애플리케이션을 만드는 소프트웨어 개발 방법론. 소프트웨어를 완제품으로 개발하던 기존 방식과 달리 부품 역할을 하는 소프트웨어 컴포넌트를 각 기능별로 개발하고 각자에 필요한 것을 선택하여 조립함으로써 소프트웨어 개발에 드는 노력과 시간을 절약할 수 있다.

컴포넌트의 정의

- 독립적으로 실행가능하며 표준 인터페이스를 갖추고 소프트웨어의 대처가능성, 재사용성, 기능적 독립성을 갖춘 소프트웨어 집합

- 잘 정의된 하나 또는 그 이상의 인터페이스를 가지는 소프트웨어의 단위 조각

컴포넌트의 특징

- 실행환경에서 독립적으로 개발, 배포될 수 있음

- 개발 생산성을 획기적으로 향상시킬 수 있으며 품질의 증대를 도모할 수 있음

- 컴포넌트 구조를 사용한다면 환경 및 사용자의 요구사항에 적응 가능한 시스템을 쉽게 개발할 수 있음

- 인터페이스를 이용하여 구현 이전에 컴포넌트를 이용한 분석작업이 가능함

- 하나 이상의 클래스로 구성될 수 있으면 다음 4가지로 구분할 수 있다.

분산 컴포넌트	EJB, CORBA, COM+ 등 분산 객체 환경 지원 컴포넌트
비즈니스 컴포넌트	물리적으로 배포할 수 있는 독립된 하나의 비즈니스 개념을 구현한 컴포넌트
확장 비즈니스 컴포넌트	확장을 고려하여 설계된 Business Component의 집합으로 그룹형태로 재사용이 가능한 항목의 집합체
시스템 컴포넌트	비즈니스 가치를 제공하기 위해 같은 일을 하는 시스템 수준의 컴포넌트들의 집합

컴포넌트 재사용의 장점

- 소프트웨어 개발기간 단축, 개발비용 감소, 생산성 증대 효과

- 테스트된 컴포넌트 사용으로 리스크 감소, 비즈니스 규칙을 적용한 일관성 확대

CBD의 정의

테스트가 완료된 소프트웨어 컴포넌트를 조립하여 사용자의 요구에 맞는 응용 소프트웨어를 만드는 방법으로 전통적 개발방법론 개념을 수용하면서 새로운 웹 기반 개방형 아키텍처를 수용하려는 소프트웨어 공학적인 접근 개발 방법. 기존 객체지향 분석/설계에서 상속을 제외하고 인터페이스 중심의 접근을 강화한 재사용 프레임웍을 수용하는 방법론

“CBD = CD+CBSD(컴포넌트 개발+컴포넌트 적용 응용개발)”

CBD의 등장 배경

- 기업환경 변화에 따른 소프트웨어 대형화, 복잡화

- 복잡성과 유지보수 비용의 증가 : 70% 이상의 유지보수 비용

- 개발 생산성 향상과 높은 질의 소프트웨어 요구

- 객체지향 방법은 단일언어로 개발하고 수시로 모듈을 수정하여 재컴파일해야하는 불편함이 있다.

CBD의 특징

- 개발시 처음부터 컴포넌트 재사용 기술을 통하여 잘 정의되고 검증된 컴포넌트를 활용함으로 써 개발기간 단축

- 자원에 대한 재사용성 확대 및 시장환경 변화에 능동적으로 대처

- 테스트와 디버깅 단계에서 시간을 절약

- 컴포넌트 명세서를 통한 소프트웨어 품질관리를 위한 프로세스 지원

- 인터페이스 기반의 접근방법을 통해 조직 내 복잡한 시스템 구성 속에서 일관성을 유지하기 쉬움

CBD의 장단점

구분	내용
장점	- 재사용을 통한 생산성 향상 à 반복적 활용에 의한 수익성 제고 및 개발 기간 단축, 개발 비용 감소 - 검증된 Component 사용으로 S/W 품질 수준 향상 - 지적 자산의 재활용 범위 확대 - 소프트웨어 개발, 유지보수 부문의 생산성 극대화 가능
단점	- 파라다임 변화에 따른 시행 착오 à Component 선정/제작/검증/활용 능력 부족 - 고객과의 문제 à 잦은 프로젝트 범위 변경 요청 및 지적 재산권 - 초기 선행 투자 - 조립식 정보시스템 구축에 따른 책임 소재

CBD 공정 및 활동

작업단계	공정의 흐름
요구사항 분석	현황평가 및 도메인 분석 à 요구사항정의 à 시스템 구조정의 à 개발계획 수립
분석	반복계획수립 à 유즈케이스 모델링 à UI 프로토타이핑, 유즈케이스 분석(정적/동적 모델)
설계	UI설계, 컴포넌트 정의 à 컴포넌트 설계 à 구현모델설계 à 컨버젼설계
개발	코딩 및 디버깅
구현	배치계획 à 테스트계획/실시 à 시스템 릴리즈 à 사용자교육

1. 분석단계

- 해당 반복에 대한 상세 계획 수립

- 구현할 시스템에서 제공해야 할 기능을 고개관점에서 정의

- 핵심 기능 UI 프로토타이핑을 통해 고객에게서 검증

- 비즈니스 엔티티와 사용자와 시스템간의 상호작용 체계를 정의하고 일들의 일관성 검증

2. 설계단계

- 시스템에 구현될 화면 레이아웃 정의

- 화면간의 Navigation 및 파라미터 전달 Signature를 정의,

- 컴포넌트 축출기법을 사용한 컴포넌트 식별, 컴포넌트간 연관관계를 정의, 컴포넌트의 재사용가능성 분석

- 상세 클래스 및 시퀀스 다이어그램 작성을 통해 객체의 속성 및 오퍼레이션과 객체간 메시지 전달흐름을 상세 설계

- 기존 컴포넌트를 재사용하기 위한 명세와 재사용에 필요한 Adaptor, Wrapper 명세

3. 개발 및 구현단계활동

- 프로그래밍

- 컴포넌트 명세, 인터페이스 명세, DB설계 내용을 플랫폼에 매칭 시키고 배포단위를 정의하고 물리적으로 구현함.

객체지향 방법론과 비교

구분	CBD	객체지향 방법론
개발프로세스	소규모 단위의 프로젝트로 나누어 반복과 점진 수행	전통적 SDLC를 따르며 개발 품질 향상을 위해 프로토타입 수행 가능
아키텍쳐 측면	프로젝트 시작과 함께 계획 및 표준화 수립 후 지속적 개선	명확한 아키텍쳐 제시 및 표준화가 미흡함
응용개발 기술	컴포넌트 단위의 블랙박스 상태에서 표준 인터페이스 적용(객체지향의 상속개념 없음)	객체지향 언어 적용 중심 프로그래밍(클래스 수준의 상속, 다형성 접근)
SW공학 측면	비즈니스 중점의 소프트웨어 재사용을 통한 생산성 향상	데이터 및 프로세스 융합을 통한 개발 패러다임 변화

CBD 도입전략

- 가능하면 많은 기능성의 서비스를 외부로부터 공급받는다.

- 시험 완료된 검증된 컴포넌트로부터 시스템을 구성한다.

- 비즈니스 측면에서 재사용 전략 수립

CBD 성공요인

- 프로세스 : CBD를 위한 프로세스를 구성하는 활동들과 역할을 명확하게 정의

- 자동화 : 프로세스를 적극적으로 지원하는 컴포넌트 재사용과정의 자동화 도구

- 컴포넌트 : 활용 가능한 시험을 거친 검증된 컴포넌트 카탈로그 확보

- 접근방법 : CBD을 적용하기 위해 기반구조 및 조직문화의 충분한 이해를 전제로 추진

CBD방법론의 종류

마르미-III	- 국내 방법론 - 사용자 화면 및 아키텍처 프로토타입을 이요한 위험관리 - 점진적 개발 - UML기반
Catalysis	- UML기반 - “모델링 개념”, “모델링 레벨”, “원칙” 이 핵심개념
Select Perspective	- 개발 초기에 비즈니스 프로세스 모델링의 중요성을 강조
RUP	- 표준 컴포넌트 개발 방법론 - UML 기반 - 초기 버전은 객체지향 방법론이었으며 버전업이 되면서 CDB방법론 지원 - 아키텍쳐 중심의 개발 프로세스 지원
그외	- CBE/e, CBD96, Advisor, MSF/CD, SDS CBD…

1. RUP

RUP(Rational Unified Process)는 소프트웨어 개발의 전체 생명주기를 지원하는 프로세스 프레임웍이다. 즉, 바로 적용하여 사용할 수 있는 방법론이라기보다는 다양한 유형의 소프트웨어 시스템, 도메인, 그리고 조직을 위한 프로세스의 프레임웍을 제공해준다. 따라서, 소프트웨어 개발 조직의 특정 요구사항에 맞게끔 프로세스를 조정할 수 있으며, 이것은 해당 프로젝트를 위한 Development Case에 문서화된다. RUP는 Objectory, OMT, Booch, 그리고 Rational의 접근법 등, 90년대 초반에 등장하였던 다양한 객체지향 방법론들을 통합하여 발전해왔는데, UML을 창안한 Jacobson, Rumbaugh, 그리고 Booch가 RUP 개발에 참여하였음을 고려해보면 이것은 결코 우연이 아니다.

RUP의 구조는 “시간”의 흐름을 나타내는 가로축과 특정 시간대에 중점적으로 수행해야 할“활동”을 보여주는 세로축으로 구성되는 2차원 구조를 가지고 있다. 먼저 가로축은 소프트웨어 생명주기를 시간의 흐름에 따라 4개의 단계로 나누어 구성하고 있으며, 이것이 하나의 개발 주기를 이룬다. 또한 각각의 단계는 일련의 반복을 포함할 수 있으며(inception) 단계에서는 프로젝트의 범위를 설정하고, 핵심적인 요구사항 파악 및 후보 아키텍처의 윤곽을 제시하며, 전체 프로젝트의 비용과 일정을 견적하고, 잠재적인 위험 요소를 식별한다. 이어지는 정련(elaboration) 단계에서는 대부분의 기능적 요구사항이 정의되고, 안정적인 아키텍처가 설계되며, 그리고 프로젝트 계획이 수립된다. 대부분의 구현과 테스트 작업은 다음에 이어지는 구축(construction) 단계에서 수행된다. 마지막으로 전이(transition) 단계에서는 베타 테스트가 수행되고, 사용자 교육이 시행되며, 소프트웨어를 사용자에게 인계하게 된다. 반면에 세로축은 전통적인 소프트웨어 개발 접근법에서의 절차와유사한 9개의 핵심 워크플로우(workflow, 최근에는 discipline이라는 개념으로 바뀌었다)를 보여주고 있다. 각각의 반복은 정의된 모든 워크플로우를 포함하지만, 앞서 언급한 것처럼 특정 반복이 강조하게 되는 워크플로우는 단계가 진행함에 따라서 변하게 된다. 초기의 반복에서는 주로 요구사항을 정의하는데 대부분의 노력을 들이지만, 다음 반복에서는 점차 분석 및 설계, 그리고 구현쪽에 중점을 두게 된다. 그리고, 최종적으로는 테스트와 배포에 더 많은 비중을 두게 된다.

RUP는 유스케이스, 아키텍쳐, 패턴, 그리고 컴포넌트 등 현대 소프트웨어 공학이 일반적으로 다루고 있는 거의 모든 기법과 산출물들을 포괄하고 있는 기능이 매우 풍부한 방법론이다. 더욱이 RUP는 반복적(iterative)이고 점진적인(incremental) 방법으로 이 산출물들을 정제하는 활동을 강조하고 있다. 이것은 위험요소를 조기에 발견하여 사전에 위험을 최소화시키고, 요구사항의 변화를 효과적으로 수용함으로써 소프트웨어의 품질을 향상시키게 된다. 무엇보다도 RUP의 가장 큰 특징은 소프트웨어 개발에 있어서 그 동안의 성공적인 경험을 바탕으로 한 6가지의 베스트 프렉티스(best practices)를 강조하였으며, 개발 프로세스를 자동화 시켜주는 다양한 도구와 이것을 방법론에 적용하기 위한 방안(Tool mentors)을 제공하고 있다는 점이다.

방법론의 기능이 풍부하다는 것은 RUP의 강점이 될 수도 있지만, 오히려 약점으로 작용할 수도 있다. RUP는 최근 소프트웨어 공학의 거의 모든 베스트 프렉티스를 포함하고 있지만, 이들 사이에서 필연적으로 발생하게 되는 긴장 상태를 어떻게 해결할 지에 대한 구체적인 지침이 부족하다. 예를 들어, RUP는 “유스케이스 중심적(기능지향적)”임과 동시에 “아키텍쳐 중심적(객체지향적)”적이지만, 이 둘 사이에 충돌이 발생했을 경우에 어느 것을 우선시해야 할지에 대해서는 명확히 설명하고 있지 않다. 또한, 방법론이 비록 수행할 작업을 작은 반복으로 나누어 놓고 있기는 하지만, 대부분의 반복이 모든 핵심 워크플로우를 수행하는 것은 아니다. 그러므로, 시스템에 대한 전반적인 분석과 설계 활동이 수행되기 전까지는 코딩이나 테스트같은 구체적인 구현 활동들은 여전히 행해지지 않는다. 결국, 폭포수형 모델의 기본 개념이 그 배경에 깔려있으며, 산출물과 프로세스 절차 구성에 큰 영향을 미치고 있다.물론 RUP는 소프트웨어 컴포넌트의 개념을 충분히 지원하고 있지만, 방법론을 주의 깊게 살펴보면 몇 가지 문제점을 안고있다. 우선, RUP가 컴포넌트 기반 개발을 지원할 수 있는 방법은 외부의 이벤트를 시작점으로 관련 있는 기능들을 하나로 묶어 이것을 하나의 컴포넌트로 정의하는 방법, 클래스간에 서로 긴밀하게 협력하는 클래스 그룹을 식별하고 이들의 결합 정도를 고려하여 컴포넌트를 정의하는 방법, 그리고 아키텍처 수준에서 식별된 서브시스템을 기준으로 컴포넌트를 정의하는 방법 등이 있다. 먼저, 첫번째와 두번째 방법은 초기 정련 단계에서 수행하게 되며, 마지막 세번째 방법은 구축 단계에서 수행된다. 컴포넌트는 클래스와 패키지의 속성을 모두 갖는다는 점에서 UML의 서브시스템의 개념과 매우 유사하지만, 이것은 자칫 컴포넌트를 전체 개발 과정 중 구현과 배포 단계에서만 중요한 역할을 갖게 되는 것으로 취급할 수 있다. 이것은 RUP가 전체 생명주기에 걸쳐 컴포넌트의 개념을 충분히 지원하지 못하고 있음을 의미한다. 또한, UML Reference Manual에는 “서브시스템은 자신의 행위를 갖지 않는다”라고 기술되어 있다. 즉, 서브시스템이 자신과 관련한 행위를 갖더라도, 이것은 자신의 고유한 행위가 아니라 서브시스템을 구성하고 있는 모델 요소들의 행위를 포함한다는 것을 의미한다. 결국 서브시스템은 다른 요소들에 의해서 구현되어져야 하는 행위를 한데 모으고 보여주기 위한 컨테이너로서 사용되며, 실제 시스템 구현에는 영향을 주지 않는다. 그럼에도 불구하고, RUP는 최근의 객체지향 소프트웨어 공학 방법론들의 수많은 구성 요소들을 이용하기 위한 유용한 프레임웍을 제공하였으며, 어떻게 이것들을 함께 적용할 수 있는지 보여주었다. 또한, 폭 넓은 사용자 층과 수많은 프로젝트를 통해 만들어진 방대한 자료는 여전히 우리가 RUP에 매력을 느끼기에 충분하다.

2. Catalysis

Catalysis는 UML을 컴포넌트 기반 개발에 적용한 최초의 방법론 중에 하나이다. 아키텍처, 패턴, 프레임웍 등의 많은 재사용 기술들을 수용하고 있으며, 오늘날 컴포넌트 기반 개발을 위해 필수 요소라고 생각하고 있는 수많은 아이디어를 소개하고 전파하였다. 객체지향 접근법은 우리가 실세계를 이해하고 있는 것과 최대한 가까운 방식으로 소프트웨어를 표현하여, 전통적인 유지보수의 문제를 해결하고자 하였다. 마찬가지로 Catalysis는 정보 및 기능을 추상화하고 있는 오브젝트(object)와 이들간에 상호작용들의 집합을 나타내는 액션(action)이라는 개념을 통해서 이러한 아이디어를 지원하고 있다. Catalysis의 또 한가지 주목할만한 특징은 컴포넌트의 구문적인 측면(예를 들어, 다이어그램)과 더불어, OCL과 같은 제약어를 사용하여 컴포넌트의 의미적인 측면(예를 들어, 사전/사후조건)을 함께 기술할 수 있는 방안을 제시했다는 점이다. 컴포넌트의 의미적인 측면이 명세에서 누락되거나 그것을 자연어와 같은 비정형적인 언어로 기술한다면, 우리는 컴포넌트의 올바른 사용과 명세의 명확성 및 정확성을 보장할 수 없게 된다. Catalysis는 “모델링 개념”, “모델링 레벨”, 그리고 “원칙”의 세가지 핵심적인 차원으로 구성되며, 각각은 다시 세가지 기본 아이디어들로 구성된다. 먼저 Catalysis는 “타입”, “콜래보레이션”, 그리고 “정제”의 세가지 아이디어를 모델링을 위한 기본 개념으로 삼고 있다. 타입은 오브젝트의 외적 행위를 추상적으로 정의하고 있으며, OMT와 Fusion에서 사용하였던 오브젝트 모델의 개념을 받아들여 컴포넌트의 타입 모델을 정의하기 위한 기반을 제공하고 있다. 콜래보레이션은 오브젝트들간에 추상적인 상호작용들의 집합으로써, 상대편 오브젝트에 대해서 일정한 역할을 수행하고 있음을 정의하고 있다. 이것은 Catalysis의 가장 핵심적인 설계 단위이다. 마지막으로 정제는 시스템의 특정 부분을 극단적인 수준까지 확대 또는 축소하더라도 동일한 기본구조가 유지되는 프랙탈의 개념을 근간으로 하고 있으며, 이것은 재귀적인 개발을 위한 초석을 제공하였다. Catalysis는 여기에 덧붙여서, 앞서의 세가지 개념들의 반복적인 패턴을 정의하기 위한 프레임웍의 개념을 강조하고 있다.

Catalysis는 시스템을 모델링 레벨에 따라서 "비즈니스", "컴포넌트 명세", 그리고 "내부 설계"의 세가지로 구분하여 설명하고 있다. 비즈니스는 시스템이 동작하게 될 외부의 환경이나 배경을 정의하며, 컴포넌트 명세는 외부로 드러난 컴포넌트 혹은 시스템의 행위를 정의하고 있다. 마지막으로 내부 설계는 컴포넌트가 어떤 부품들의 조합으로 만들어져 있으며, 이러한 부품들이 내부적으로 어떻게 상호작용을 하게 되는지를 정의하고 있다.

Catalysis를 구성하는 마지막 차원에서는 “추상화”, “구체화”, 그리고 “조립부품”을 소프트웨어 개발을 위한 원칙으로 제시하고 있다. 추상화는 개념 혹은 산출물에서 관심 밖의 상세한 내용을 제거하고 문제와 관련 있는 것만을 분리한다. 구체화는 추상적으로 기술된 산출물을 구체적이고 정밀하고 테스트 가능하게 개발하는 것을 말한다. 조립부품은 서로 조립하여 사용할 수 있는 융통성 있는 소프트웨어 빌딩블록을 의미한다. 이러한 다양한 개념과 원칙들은 소프트웨어 개발 프로젝트의 생산성 향상에 도움을 주며, 소프트웨어 개발의 많은 문제들을 해결하는데 필요한 모든 개념적인 장치를 마련해 주었다. 하지만, 그렇기 때문에 방법론이 복잡하고, 일반적인 개발자가 쉽게 습득하기 어렵다는 점은 Catalysis가 갖는 약점이 될 수 있다.

하나의 프로세스가 모든 프로젝트의 다양한 요구사항이나 제약사항을 만족시킬 수는 없으며, 따라서 Catalysis는 고정적인 프로세스 보다는, 다양한 개발의 요구사항을 수용할 수 있도록 고안된 프로세스 패턴(process patterns)을 제공하고 있다. 즉, 비지니스 모델, 컴포넌트 명세, 컴포넌트 구현, 그리고 조립과 재사용 등은 각각 하나의 단일 프로세스를 갖는 것이 아니라, 다양한 개발 요구에 따라 각자의 프로세스 패턴들과 이에 따른 지침을 제공하였다. 그러나, 프로세스를 정의하는데 패턴을 사용함으로써 방법론이 규정적이지 못하고, 사용자에게 체계적인 방법으로 시스템을 개발하기 위한 구체적인 지침을 제시하지 못하고 있다. 이것은 대다수의 개발자들이 Catalysis를 쉽게 적용하는데 있어서 큰 장애요인이 된다. 뿐만 아니라, 앞서 언급한 것처럼 Catalysis는 컴포넌트의 의미적인 측면을 기술하기 위해 OCL을 사용하고 있다. OCL이 VDM이나 Z같은 로직보다 습득하기 쉽기는 하지만, 여전히 이점은 방법론의 대중적인 보급을 제한하는 결과를 초래하였다. 결론적으로 Catalysis는 컴포넌트 개발에 대하여 다소 복잡하고 학문적인 접근을 했으며, 만약 누군가 상업적인 프로젝트에 이 방법론을 사용하고자 한다면 그 아이디어들을 보다 유용하게 단순화하고 정리해야 할 것이다. 이러한 문제점들에도 불구하고, Catalysis는 타입 모델(type model), 행위 정제(actionrefinement), 재귀적인 프로세스(recursive processes), 그리고 모델링 언어에서 콜래보레이션(collaboration)을 핵심적인 도구로 사용하는 등 컴포넌트 기반 개발이 반드시 지원해야 하는 대부분의 필수 요소들에 대한 밑그림을 제시하였다.

3. Select Perspective

Select Perspective는 앞에서 설명한 Catalysis와 비슷한 시기에 만들어진 컴포넌트 기반 개발 방법론이다. 이 방법론은 개발 초기에 비지니스 프로세스 모델링의 중요성을 강조하고 있으며, 비지니스 프로세스를 구현 모델로 단계적으로 전환하기 위한 명확한 프로세스를 정의하고 있다. 또한 여기에는 명시적인 컴포넌트 식별 뿐만이 아니라, 레가시 시스템을 통합하기 위한 프로세스도 포함된다. Select Perspective의 가장 큰 강점은 실제 현장에서의 경험을 통해 만들어졌기 때문에 실용적인 지침과 안내서가 매우 풍부하다는 점이다. 또한, 방법론과 더불어 컴포넌트 설계/개발 및 관리도구, 프로세스 관리도구, 그리고 솔루션 등 상업적인 도구의 지원이 풍부하다는 점은 방법론을 더욱 실용적으로 만들어주었다(Select 제품군은 얼마전 Princeton Softech으로부터 Aonix사에 매각되었다). Select

Perspective는 성공적인 소프트웨어 개발을 위해 다음의 7가지 원칙을 제시하고 있다.

A. 비즈니스 프로세스와 소프트웨어의 연계.

B. 실용적인 컴포넌트 기반 개발.

C. 비즈니스 프로세스 모델링, 컴포넌트 모델링, 그리고 데이터 모델링의 통합.

D. 반복적이고 점진적인 개발.

E. 작업의 분할을 통한 병렬적인 개발.

F. 고품질의 아키텍처를 적용.

G. 통합 개발 도구의 지원.

이러한 원칙들은 고품질의 소프트웨어 생산을 보장하며, 조직의 CBD 보급을 활성화하고, 위험요소를 조기에 식별할 수 있게 한다. 또한, 여러 컴포넌트를 동시에 개발함으로써 제품의 전체적인 인도시기를 앞당길 수 있고, 안정적인 아키텍처를 사용하여 보다 설계에 필요한 시간을 단축시켜 준다. Select Perspective는 앞서 언급한 RUP와 유사하기도 하지만, 매우 독특한 구조를 가지고있다. 이 방법론을 적용한 프로젝트는 시간의 흐름이 따라 정렬(align), 설계(architect), 조립(assembly)의 세가지 단계로 진행되며, 각각의 단계는 다시 하나 이상의 증분(increment)으로 나뉘어 작업을 수행한다. 그리고, 하나의 증분이 수행되는 동안 비즈니스 계획, 비지니스 아키텍처, 테크니컬 아키텍처, 컴포넌트 관리, 컴포넌트 개발, 솔루션 개발의 6가지 활동들이 병렬적으로 진행된다. 우리는 방법론의 구조를 굳이 자세하게 살펴보지 않아도, 이미 이러한 구조가 앞서 말한 7가지의 원칙을 잘 따르고 있음을 미루어 짐작할 수 있다. 하나의 증분 안에서 병렬적으로 수행되는 활동들은 RUP의 워크플로우와 유사하게 프로젝트가 진행하면서 좀 더 강조되는 부분이 있다. 즉, 정렬 단계에서는 비즈니스 설계(비즈니스 프로세스 모델링), 설계 단계에서는 아키텍처 설계(컴포넌트 모델링), 그리고 조립 단계에서는 개발(컴포넌트 개발) 활동에 보다 중점을 두고 수행하게 된다. 결국, 단계가 진행함에 따라서 비즈니스 프로세스가 정의되며, 이를 토대로 점차 아키텍처가 수립되고, 각각의 증분은 가시적인 결과물을 만들어낸다. 최종적으로는 이러한 결과물들이 모여 완벽한 솔루션을 생산해 내게 된다.

Select Perspective의 가장 강력한 특징 중에 하나는 바로 LUCID 기법이다. 이 기법은 경험을 바탕으로 만들어진 설계와 개발 기법으로서, 컴포넌트 관리를 제외한 5개의 병렬 활동에모두 적용되는 매우 실용적인 지침을 제공하고 있다. Select Perspective의 가장 큰 약점은 비즈니스 오브젝트를 설명하고 있는 모델의 구분이 다소 모호하다는 것이다. 예를 들면, 어떤 모델이 비즈니스 오브젝트 혹은 컴포넌트의 명세를 정의하고 있는지, 어떤 모델이 비즈니스 오브젝트 혹은 컴포넌트의 동작과 관련한 설계를 정의하고 있는지를 쉽게 알기 힘들다. 또한, 중첩된 컴포넌트 계층 구조(hierarchy of nested components)를 지원하기 위해 이들 모델과 활동들을 어떻게 재귀적으로 적용할 수 있는지가 분명치 않다.

4. Advisor(CBD96)

Advisor는 Sterling Software(현재 Computer Associates사에 합병되었다)의 개발도구를 지원하기 만들어진 방법론이다. 컴포넌트 기반 개발과 비지니스 프로세스 개선에 초점을 맞추고 있으며, 방법론 프레임웍, 비지니스 프로세스 개선 및 컴포넌트 기반 개발 프로세스, 컴포넌트 표준(CBD96), 그리고 기법을 제공한다. 우리가 흔히 방법론으로 오해하고 있는 CBD96(현재는 CS/3.0으로 업그레이드 되었다)은 프로세스라기 보다는 COM+나 EJB와 같은 컴포넌트 표준이다. 따라서, 현재의 Windows나 Unix 환경에서는 CBD96과 같은 컴포넌트 환경은 별로 유용해 보이지 않는다. 하지만, 메인프레임 환경에서 COBOL 언어를 사용하는 개발자라면 이와 같은 컴포넌트 표준은 아직도 매우 유용하게 쓰일 수 있다. Advisor는 상단의 애플리케이션 개발 트랙과 하단의 컴포넌트 공급 트랙으로 구성되어 있으며, 각기 컴포넌트 기반 개발(CBD)과 단일 컴포넌트 개발(CD)을 지원하게 된다. 두 개의 트랙은 모두 시간의 흐름에 따라 요구사항 정의, 분서, 아키텍처 설계, 행위 명세, 내부 설계, 코딩 및 단위 테스트, 조립 테스트, 그리고 인도 단계로 나뉘어지는 8개의 타스크를 상호 협력하면서 동시에 수행한다. 예를 들어, 애플리케이션 개발 트랙의 아키텍처 설계 단계에서 필요한 컴포넌트가 식별되었다면, 이것은 하단의 컴포넌트 공급 트랙을 통해 개발 혹은 조달하게 되고, 여기서 개발된 컴포넌트는 다시 상단의 조립 테스트 단계로 공급되어 다음 단계를 계속 진행할 수 있게 된다. 이러한 구조 때문에 방법론이 전통적인 폭포수형 모델을 따르고 있는 것처럼 보일 수도 있겠지만, 사실 두 개의 트랙은 모두 하나 이상의 반복을 통해 점진적인 개발을 할 수 있도록 설계되었다. 특히, 컴포넌트 공급 트랙은 다시 그 하단에 컴포넌트 공급 트랙을 포함함으로써, 컴포넌트를 조립하여 보다 큰 규모의 컴포넌트를 개발할 수 있도록 지원하고 있다. 또한, 공급되는 컴포넌트의 형태에 따라서 컴포넌트 공급 트랙에서 수행하게 되는 타스크의 내용은 유동적일 수 있다. 즉, 컴포넌트를 처음부터 개발하는 것이 아니라, 외부 로부터 컴포넌트를 조달한다면 8가지의 타스크를 전부 수행할 필요는 없을 것이다.

Advisor는 컴포넌트 기반 개발을 시도하려는 많은 개발들에게 매우 유용하고 실질적인 접근법을 제시하였으며, Catalysis의 수많은 아이디어를 현실화 시킴으로써 시장에서 큰 환영을 받았다. 하지만, 앞으로 더 이상의 업그레이드가 이루어지지 않을 계획이라는 점은 이 방법론을 도입하려는 개발자들이 한번쯤 고민해보아야 할 문제이다. 또한, 지금까지의 다른 방법론들과 마찬가지로 누구나 쉽게 시도해볼 수 있는 구체적인 컴포넌트 식별방법을 제시하지 못하였으며, 많은 부분을 숙련된 개발자의 경험에 의존하고 있다. 마지막으로, 이 방법론은 Select Perspective와 마찬가지로 개발도구에 막강한 지원을 받기도 하지만, 반대로 특정 개발도구에 종속적이라는 비판을 받아왔다. 이러한 문제점들에도 불구하고, Advisor는 Catalysis의 아이디어를 정리하고 단순화시켜서 일반적인 개발자로 하여금 보다 쉽게 CBD를 실현할 수 있도록 도와주었다. 더군다나 컴포넌트를 그 관점에 따라 명세, 구현, 그리고 실행물로 나누어 각자의 관심 영역을 명확히 구분하였고, 개발의 초기 단계부터 인터페이스의 역할을 강조하고 있다. 또한, 컴포넌트를 모델링하는 과정에서 흔히 만나게 되는 다양한 문제들을 해결하기 위한 실질적인 기법들을 제시하였다.

5. MaRMI-III(Magic and Robust Methodology Integrated)

마르미-III는 한국전자통신연구원과 숭실대학교가 공동으로 개발한 FOCUS(Family Oriented Component System Methodology)를 프로타입으로하여 지난 2001년에 발표된, 컴포넌트 기반 개발 방법론이다. FOCUS는 시스템 패밀리의 서로 다른 멤버들이 갖는 요구사항들을 정규화하여, 이들의 공통성과 가변성을 분석하기 위한 기법을 제공하였으며, 유스케이스와 관련 클래스를 클러스터링하여 컴포넌트를 식별할 수 있는 기계적인 방법을 제안하였다. 또한 Advisor와 마찬가지로 컴포넌트 기반 개발과 컴포넌트 개발을 모두 지원하며, 작업공정을 몇 개의 층으로 나누어 번호를 통해 프로젝트를 관리할 수 있는 체계(numbering scheme)를 만들었다. 이것을 바탕으로 개선되어진 마르미-III는 전체적인 구조에 있어서 앞에서 설명한 RUP와 매우 유사한 형식을 취하고 있다. 마르미-III의 특징 중에 가장 주목할 만한 것은 컴포넌트를 고려한 여러 개의 미니프로젝트를 통하여 반복적이고 점진적인 개발을 지원하고 있고, 개발의 초기부터 견고한 아키텍처를 정의하여 사용하고 있으며, 그리고 무엇보다도 절차서, 기법정의서, 양식정의서, 적용사례 등이 방법론과 함께 제공된다는 점이다. 특히 적용사례는 CBD를 처음 도입하려는 개발자에게 매우 유용한 도구가 아닐 수 없다. 물론 이 모든 것들은 한글로 제공된다. 또한, 마르미-III는 앞서 언급한 다양한 CBD방법론의 강점을 취합하였을 뿐만 아니라, 소프트웨어 컴포넌트 기술을 선도하고 있는 기업들의 다양한 아이디어들을 수렴하여 국내의 실정과 정서에 맞게끔 개발되었다. 또한, 컴포넌트를 위한 산출물 표준, 품질 표준, 유통 표준, 그리고 응용 표준 등을 위해 활동하는 다른 조직들과 연계하여 방법론을 개선하고 있다는 점은 매우 주목할만한 사항이다.

최근에 마르미-III는 마르미-III 2.0으로 업그레이드되었다. 새로운 버전의 가장 큰 특징은 EJB 기반의 프로젝트를 위한 절차 및 지침을 강화했다는 점과 관리 프로세스를 더욱 보강하여 개발 프로세스와 완전히 분리시켰다는 것이다. 이로써 방법론은 이 두 가지 프로세스가 혼합됨으로써 발생하였던 중복성이 상당부분 해소되었으며, 독립적인 프로젝트 계획, 통제, 그리고 평가활동이 가능해졌다. 또한 마르미-III는 앞으로도 지속적인 개선작업을 통해서. NET 버전(마르미-III 3.0)과 Web Services 버전(마르미-III 4.0)을 계속 발표할 예정에 있다.

방법론이 특정 컴포넌트 플랫폼에 종속적이라는 사실은 서로 상충되는 측면을 내포하고 있는데, 이것은 방법론의 유연성을 떨어뜨릴 수 있지만 각각의 컴포넌트 플랫폼이 고유의 아키텍처를 제공하고 있음을 고려한다면 이것은 매우 실질적인 접근법이 될 수도 있다. 마르미-III의 또 다른 문제점은 개발의 초기부터 아키텍처를 강조하고 있지만, 그 개념이 매우 모호하여 일반 사용자가 이러한 강점을 충분히 활용하기 어렵다는 점이다. 마지막으로 마르미-III는 반복 개발을 포괄적으로 지원하지 못하는 것처럼 보이며, 실질적으로도 대부분의 사용자들은 일부 단계에서만 반복 개발의 개념을 적용하고 있다. 이것은 방법론이 갖는 구조적인 문제점 때문이다. 예를 들어, 마르미-III 2.0는 중첩된 박스 구조로 구성되어 있는데, 개발 프로세스의 경우 요구획득, 아키텍처, 점진적개발, 인도의 4개의 단계로 구성되며, 이것은 다시관리 프로세스에 의해서 통제를 받는다. 여기서 점진적개발 단계는 다시 하나 이상의 미니프로젝트로 나뉘어 병렬적으로 수행되거나 순차적으로 수행될 수 있다. 따라서, 마르미-III에서의 대부분의 반복은 점진적개발 단계에 국한되어 있다고 볼 수 있다.

6. 기타 CBD 방법론

여기서 간단하게 소개하려고 하는 CBD 방법론들은 앞서의 그것들과 비교해 보았을 때 그 사용 목적이 매우 특이하다. 먼저 “UML Components”는 소프트웨어 컴포넌트의 핵심 개념 중에 하나인 컴포넌트 명세 작성을 위한 가장 간단하고 실용적인 프로세스를 제공해주고 있다. 이 방법론은 앞서 언급한 Catalysis와 Advisor 방법론에 큰 영향을 받았으며, RUP를 부분적으로 수용하고 있다. UML Components는 컴포넌트를 위한 많은 개념들과 공정 및 지원 활동들이 생략되어 있지만, CBD 도입에 부담을 갖기 쉬운 초보자라도 쉽게 습득할 수 있다는 장점을 가지고 있다.

독일의 프라운호퍼 IESE(Institute for Experimental Software Engineering)가 주도적으로 개발에 참여한 “KobrA”는 사실 컴포넌트보다는 컴포넌트를 기반으로 하여 제품라인(Product Line)을 개발하기 위한 프로세스이다. 즉, 제품 패밀리를 위한 프레임웍을 만들어, 특정 멤버를 위한 애플리케이션을 개발할 수 있도록 고안되었다. 방법론은 크게 프레임웍 엔지니어링과 애플리케이션 엔지니어링으로 구성되는데, 프레임웍 엔지니어링 단계에서는 시스템 패밀리의 공통적인 부분은 물론 가변성을 추가하여 프레임웍을 만들게 되고, 애플리케이션 엔지니어링 단계에서는 이러한 가변성을 제거하여 특정 멤버의 요구사항에 맞는 애플리케이션을 개발하게 된다. 이러한 공정이 복잡하게 보일 수도 있지만, KobrA는 “관심의 분리(separation of concerns)” 개념을 적용하여 프로세스와 산출물을 엄격하게 구분함으로써 방법론을 단순화하였다. 또한, 방법론을 추상화, 일반화, 그리고 조립의 정도에 따라서 세 개의 독립적인 차원으로 구성하여, 컴포넌트 모델이 어떻게 구체적인 형태로 바뀔 수 있는지 체계적으로 설명하였다. 이전의 방법론에서는 UML 모델과 구현 산출물 사이에 많은 격차가 있었던 것이 사실이다. 그리고 프레임웍을 구성하는 컴포넌트들을 트리 구조로 정의하여, 트리안에 모든 컴포넌트들이 동일한 일관성 규칙(consistency rules)에 적용을 받게 하였으며, 프로세스를 재귀적으로 구성할 수 있다는 것 또한 KobrA가 가지고 있는 장점 중에 하나이다.