CBD 개발방법론

CBD 개발방법론(Component Based Development)이란 컴포넌트를 조합해 재사용함으로써 개발 생산성과 품질을 높이고 시스템 유지보수 비용을 최소화할 수 있는 개발방법론이다. 컴포넌트 기반 개발방법론이라고 한다.

개요

특정 기능 수행을 위해 독립적으로 개발, 잘 정의된 인터페이스(I/F)를 가지며, 다른 부품과 조립되어 응용시스템 구축에 사용되는 SW 단위를 컴포넌트라고 하는데, 개발된 S/W 컴포넌트를 조립, 시스템을 개발하여 객체지향의 단점인 S/W 재사용성을 극대화한 개발방법론을 'CBD 개발방법론'이라고 한다.

등장 배경

CBD의 등장 배경은 다음과 같다.

• 기업환경 변화에 따른 소프트웨어 대형화, 복잡화 현상이 발생했다.
• 복잡성과 유지보수 비용의 증가: 70% 이상의 유지보수 비용을 요구한다.
• 개발 생산성 향상과 높은 질의 소프트웨어를 요구한다.
• 객체지향 방법은 단일언어로 개발하고 수시로 모듈을 수정하여 재컴파일해야하는 불편함이 있다.

CBD 개발 방법론 등장배경

특징

객체지향 개발 방법론

CBD 개발 방법론 개념도

객체지향 개발 방법론에서는 분석, 설계, 구현의 전 과정을 객체 중심으로 진행된다. 데이터를 저장하는 테이블도 따로 설계하지 않고 데이터 객체로 설계한다. 데이터는 결국 데이터베이스에 저장되는데 만일 데이터베이스가 객체형 데이터베이스이다. 별다른 변환과정 없이 데이터 객체를 그대로 저장하면 되지만, 관계형 데이터베이스를 사용하여 객체를 관계형 테이블로 변환하는 과정이 필요하다. 이 과정을 객체관계 매핑(Object Relation Mapping)이라 하며, 대부분의 회사에서 관계형 데이터베이스를 사용하고 있기 때문에 객체관계 매핑은 필수적인 과정이다. 객체지향 개발 방법론은 실 세계를 정확하게 반영하며, 높은 재사용성과 안정성을 갖고 있다는 장점이 있지만, 관계형 데이터베이스로 구성되어 있는 산업계에서는 객체관계 매핑 과정이 필수적이기 때문에 활발하게 사용되지는 않는다. 관계형 데이터베이스에서 제공하는 에스큐엘(SQL)은 풍부한 기능을 가지고 있어 많은 개발자 들이 이 분야에서 지식과 노하우를 축적하고 있다. 또한, 관계형 데이터베이스에서 객체형 데이터베이스로의 이전을 가로막는 장애물이 되고 있다. 많은 프로젝트에서 자바와 같은 객체지향 언어를 사용하기 때문에 프로세스 설계 과정에서는 객체지향 개발 방법론 개념이 많이 사용되고 있으며, 데이터 설계 과정에서는 기존의 정보공학 방법론이 많이 사용된다. 즉, 프로그램은 객체지향 언어를 사용하고 데이터베이스는 관계형으로 설계한다.

구분	설명
생산성	* 부품 조립을 통한 어플리케이션 개발 시간을 단축한다. * 개발자의 생산성 향상, 품질이 검증된 컴포넌트를 사용한다.
고품질	* 지속적인 품질 관리로 검증된 컴포넌트의 사용. * 품질을 고려한 컴포넌트를 설계 및 구현한다.
재사용과 대체성	* 실행 기반의 재사용    (동일 기능의 중복 개발 없이 기존에 개발된 컴포넌트를 이용하여 새로운 시스템 구축) * 모델과 프레임워크 기반의 재사용    (다른 컴포넌트에 영향, 시스템 전체 변경 없이 새로운 기능 추가 및 컴포넌트 대체)
변경 용이성	* 요구사항의 변화와 수용에 안정적이고 신속한 변경 가능하다. * 업무 변경에 따른 위험을 최소화한다.
기술 집약성	* 기술 숙련에 대한 집중 * 아키텍처, 프레임워크, 분산 객체 기술
관리 용이성	* 독립적인 컴포넌트 단위의 관리로 복잡성 최소화. * 제작주기에 대한 예측 가능 * 제품 외주화 및 구매에 대한 선택 기회를 부여한다.
사용자 중심	* 사용자 관점 요구사항 분석으로 컴포넌트를 식별가능하다. * 사용자 중심의 개발로 사용자 만족도 증가.

장단점

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

개발 절차

단계	활동	세부내용/산출물
요구파악
	요구사항 이해	* 사용자 요구사항 수집, 도메인 분석. * 요구사항 기술서, 용어사전, 개념 모델
	요구사항 정의	* 요구사항 이해 기반, 유즈케이스 작성. * Usecase Model
분석 및 설계
	요구사항 분석	* 객체 모델 프로토타이핑, UI 기획 * 객체 모델, UI 설계서
	아키텍처 정의	* 소프트웨어 컴포넌트 아키텍처 정의 * 아키텍처 기술서
	컴포넌트 설계	* 아키텍처 기반 I/F 명세화, 모델링 * 인터페이스 명세서 , 컴포넌트 명세서
	데이터베이스 설계	* 객체 모델의 엔티티 클래스를 대상으로 DB 모델링 * ERD, DB 설계서
구현
	개발표준 정의	* 플랫폼 특성 검토, 표준 수립 * 명명규칙, 코딩규칙, 프로그래밍가이드
	코드 구현	* 플랫폼 따른 전용 Compiler 이용
테스트
	테스트 계획	* 테스트 목표, 대상, 방법, 절차수립 * 테스트 계획서
	테스트 수행/보고	* 테스트 수행, 절차 기록 및 승인 * 컴포넌트 테스트 통합테스트 인수테스트 보고서

CBD 방법론 종류

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에 매력을 느끼기에 충분하다.

카타리시스

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

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

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

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

Select Perspective

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

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

1. 비즈니스 프로세스와 소프트웨어의 연계.
2. 실용적인 컴포넌트 기반 개발.
3. 비즈니스 프로세스 모델링, 컴포넌트 모델링, 그리고 데이터 모델링의 통합.
4. 반복적이고 점진적인 개발.
5. 작업의 분할을 통한 병렬적인 개발.
6. 고품질의 아키텍처를 적용.
7. 통합 개발 도구의 지원.

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

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

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를 실현할 수 있도록 도와주었다. 더군다나 컴포넌트를 그 관점에 따라 명세, 구현, 그리고 실행물로 나누어 각자의 관심 영역을 명확히 구분하였고, 개발의 초기 단계부터 인터페이스의 역할을 강조하고 있다. 또한, 컴포넌트를 모델링하는 과정에서 흔히 만나게 되는 다양한 문제들을 해결하기 위한 실질적인 기법들을 제시하였다.

마르미-III

마르미-III(Magic and Robust Methodology Integrated)는 한국전자통신연구원과 숭실대학교가 공동으로 개발한 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에서의 대부분의 반복은 점진적개발 단계에 국한되어 있다고 볼 수 있다.

컴포넌트

• 독립적으로 실행가능하며 표준 인터페이스를 갖추고 소프트웨어의 대처가능성, 재사용성, 기능적 독립성을 갖춘 소프트웨어 집합
• 잘 정의된 하나 또는 그 이상의 인터페이스를 가지는 소프트웨어의 단위 조각
• 실행환경에서 독립적으로 개발, 배포될 수 있음
• 개발 생산성을 획기적으로 향상시킬 수 있으며 품질의 증대를 도모할 수 있음
• 컴포넌트 구조를 사용한다면 환경 및 사용자의 요구사항에 적응 가능한 시스템을 쉽게 개발할 수 있음
• 인터페이스를 이용하여 구현 이전에 컴포넌트를 이용한 분석작업이 가능함
• 하나 이상의 클래스로 구성될 수 있으면 다음 4가지로 구분할 수 있다.
• 소프트웨어 개발기간 단축, 개발비용 감소, 생산성 증대 효과
• 테스트된 컴포넌트 사용으로 리스크 감소, 비즈니스 규칙을 적용한 일관성 확대

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

CBD 방법론 핵심

성공요인

내용	설명
아키텍쳐 중심	* SW 전체 조감도를 통한 가시성 확보, 위험을 조기 식별 및 대응한다.
엔지니어링 도구	* 자동화된 툴 사용, 생산성 및 정확성을 향상 시킨다. * Stub/Driver 모듈을 이용한 사전 기능 자동 검증을 수행한다.
프레임워크 기반	* 컴포넌트의 상호 연동을 자동화하여 개발생산성 및 품질향상 기반 역활을 수행한다.
조직간R&R 명확	* 비즈니스 분석 팀, 컴포넌트 개발팀, 프레임워크 개발팀, 품질 보증 지원 팀의 명확한 역할 분담
표준 및 방법론	* 실행환경 표준: .NET, J2EE, CCM * 개발 표준: UML 기반 자동화 도구, RUP 기반 프로세스
개발팀 역량강화	* 객체지향, 컴포넌트 구현 기술 습득 정도 및 표준이해, 준수 향상 필요.
재사용 관리 체계	* 컴포넌트 재사용 지식/경험을 축적한다. * 컴포넌트 형상관리 및 품질관리 체계 구축 필수

위험요소와 대응방안

위험요소	대응방안
재사용 컴포넌트 부재	* 컴포넌트 관리체계 수립위한 전사전력 수립 * RFP에 컴포넌트 현황 공개 및 활용 권고
경험부족 및 비용 증가	* 개발 난이도 높은 부분, 사용빈도 높은 컴포넌트를 우선 도출 및 개발한다.
낮은 재사용 빈도	* 컴포넌트 표준 명세 작성 및 KMS(지식관리시스템)을 구축, 우수 적용 사례를 발굴 및 전파한다.

참고자료

• 고미, 〈CBD (Conponent Based Development)〉, 《네이버 블로그》, 2019-10-19
• 후루꾸, 〈CBD(Component Based Development) 〉, 《다음 블로그》, 2018-04-19
• 멀티코어 multicore, 〈소프트웨어 개발 방법론〉, 《티스토리》, 2018-11-19

같이 보기

• 컴포넌트
• 객체지향 개발방법론
• 소프트웨어 개발방법론

이 CBD 개발방법론 문서는 프로그래밍에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

개발 : 프로그래밍 □■⊕, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 프로그래밍 언어 ASP • C 언어 • C++ • C# • CSS • D 언어 • HTML • HTML5 • JSP • PHP • R • XHTML • XML • XSLT • 고(Go) • 고급언어 • 기계어 • 델파이 • 러스트 • 루비 • 루아 • 리액트 • 리퀴디티 • 무브 • 미켈슨 • 베이직 • 브이비스크립트 • 비주얼 C++ • 비주얼베이직(VB) • 비주얼베이직닷넷(VB.NET) • 솔리디티 • 스몰토크 • 스위프트 언어 • 스칼라 • 스크립트 언어 • 알골 • 어셈블리 • 언리얼스크립트 • 얼랭 • 에이잭스(Ajax) • 엠에프씨(MFC) • 오브젝티브-C • 오브젝트 파스칼 • 오카멜 • 웹어셈블리(WASM) • 이와즘(eWASM) • 자바 • 자바스크립트 • 저급언어 • 제이슨(JSON) • 제이쿼리(jQuery) • 카멜 • 코볼 • 코틀린 • 콜드퓨전 • 타입스크립트 • 파스칼 • 파워스크립트 • 파이썬 • 펄(Perl) • 포트란 • 프로씨(Pro-C) • 피엘에스큐엘(PL/SQL) • 피엘원(PL/I) • 하스켈 개발방법론 CBD 개발방법론 • EA • 구조적 개발방법론 • 객체지향 개발방법론 • 라이브러리 • 람다 아키텍처 • 모듈 • 모듈화 • 벤치마킹 • 소프트웨어 개발방법론 • 스크럼 • 스프린트 • 아키텍처 • 아키텍트 • 애자일 • 웹개발방법론 • 정보공학 개발방법론 • 컴포넌트 • 테일러링 • 템플릿 • 폭포수 모델 • 프로젝트 • 프로토타입 • 피드백 코딩 EUC-KR • UTF-8 • 값 • 글루웨어 • 디버깅 • 디코딩 • 마크업 • 버그 • 부트스트랩 • 세이브포인트 • 소스코드 • 시큐어코딩 • 아스키 • 액티브엑스 • 오픈소스 • 유니코드 • 인코딩 • 재컴파일 • 주석 • 컴파일 • 컴퓨터 프로그램 • 코드 • 코딩 • 태그 • 테스트 • 테이블 • 텍스트 • 파싱 • 퍼블리싱 • 퓨니코드 • 하드코딩 • 하이퍼링크 • 하이퍼텍스트 프로그래밍 C 명령어 • 객체 • 객체지향 • 객체지향 프로그래밍 • 거짓 • 관계연산자 • 기본형 변수 • 널 • 논리 • 논리연산 • 논리연산자 • 다중상속 • 다형성 • 대입 • 대입문 • 대입연산자 • 더블 • 도스 명령어 • 디폴트 • 레지스터변수 • 루프 • 리눅스 명령어 • 리턴 • 메모리 주소 • 메소드 • 멤버 • 명령문 • 명령어 • 무한루프 • 문자 • 문자열 • 바이트 • 반복문 • 배열 • 변수 • 분기 • 분기문 • 불린 • 브레이크 • 비교연산자 • 비트연산자 • 산술연산자 • 상속 • 상수 • 생성자 • 선언 • 선언문 • 설정자 • 속성 • 스위치 • 스태틱 • 시프트연산자 • 실행 • 실행문 • 어노테이션 • 에코 • 역참조 • 연산 • 연산문 • 연산자 • 오버로딩 • 오버라이딩 • 외부변수 • 윈도우 명령어 • 유닉스 명령어 • 인스턴스 • 인스트럭션 • 인클루드 • 인터페이스 • 임포트 • 입력 • 입력문 • 입출력 • 입출력문 • 자료형(데이터 타입) • 자바 명령어 • 자바 예약어 • 자바 컬렉션 • 전역변수 • 접근자 • 접근제어자 • 정보은닉 • 정수형 • 정적변수 • 제어 • 제어문 • 제어자 • 조건 • 조건문 • 조건연산자 • 주소 • 증감연산자 • 지역변수 • 참 • 참조 • 참조변수 • 초기화 • 추상메소드 • 추상클래스 • 추상화 • 출력 • 출력문 • 캡슐화 • 케이스 • 클래스 • 파라미터(매개변수) • 파이널 • 패키지 • 퍼블릭 • 포인터 • 프라이빗 • 프로텍티드 • 필드(멤버변수) • 함수 • 환경변수 명령어 abstract • array • boolean • break • byte • case • char • continue • default • double • do while • echo • elif • else • else if • false • final • float • for • gosub • goto • if • if else • import • include • int • join • long • long long • null • print • printf • println • private • protected • public • return • scanf • short • stdio.h • static • string • switch • temp • then • true • unsigned • void • while 디자인패턴 구조패턴 • 동시성패턴 • 동시실행패턴 • 모델-뷰-컨트롤러 패턴 • 상태패턴 • 생성패턴 • 싱글톤패턴 • 아키텍처패턴 • 전략패턴 • 커맨드패턴 • 행동패턴 프로그래밍 인물 귀도 반 로썸 • 그레이스 머레이 호퍼 • 니클라우스 비르트 • 댄 브릭클린 • 더그 커팅 • 데니스 리치 • 리누스 토르발스 • 리처드 그린블라트 • 마거릿 해밀턴 • 마크 앤드리슨 • 빈트 서프 • 빌 게이츠 • 빌 조이 • 스티브 잡스 • 에이다 러브레이스 • 제임스 고슬링 • 척 벤턴 • 켄 톰슨 • 팀 패터슨 위키 : 자동차, 교통, 지역, 산업, 기업, 단체, 업무, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반