XPACE

2000년대 초기부터 2005년 무렵까지 엔터프라이즈 시스템 구축을 주도하던 키워드는 한마디로 COMPONENT였다. 
CBD에 관한 책들은 우후죽순처럼 쏟아져 나왔고 CBD를 이야기 하지 않으면 프로젝트는 시작될 수 없었다. 모든 개발관련툴은 CBD를 지원한다는 광고를 실어야 했고 CBD를 모르면 개발자로 참여할 수도 없었다. 

그런데 지금 CBD는 어디에 있는가?
엔터프라이즈 시스템에서 CBD는 더이상 키워드가 되지 못하고 있다. 4GL이나 3Tier와는 너무도 다른 양상이다. 컴포넌트 개념은 Technical 문제를 다루는 곳에서 존재하지만 이것은 여전히 예전의 라이브러리 개념과 별 차이를 보이지 못하며 정작 CBD가 주장하던 비즈니스 컴포넌트 개념은 온데간데 없다. 혹시 내가 모르는 곳에서 숨어서 꽃을 피우고 있나? 아닐 것이다.

사람들은 더이상 비즈니스 컴포넌트에 집착하지 않는다. 적당히 유야무야되었다는 것이 정확할 것이다. 이런 글을 쓰고 있는 나 또한 그 시절에 CBD가 미래를 열어 줄 것이라 확신했었다. 뭔가 내가 부족하기 때문에 컴포넌트 개념을 잘 이해 못하고 그래서 내가 참여했던 프로젝트에서 비즈니스 컴포넌트 개념이 정착되지 못하는 것이라 생각했었다.

그런데 내가 이 시점에 CBD를 이야기하는 것은 정말 과거의 우리 신념에 대한 반성이 없이 새로운 키워드를 찾으려고 노력한다는 것을 지적하고 싶다. 컴포넌트 개념이 정말로 나 스스로를 포함한 모든 사람을 위선으로 빠트리기 위한 거짓부렁에 불과했는가? 아니면 일정정도 의미가 있고 가치있는 개념이었는가?

우리는 공개적으로 반성하고 정리해야 할 것이다. 그래야 미래의 새로운 키워드에 대해서 비판적으로 수용할 수 있을 것이다. 

내가 현시점에 CBD를 보는 관점은 기술적으로는 의미잇는 성과를 이루었지만 비즈니스 컴포넌트 관점에서는 실패했다고 생각한다. 나는 CBD의 가장 성공 사례로 이클립스를 꼽는다. 수많은 솔류션이 이클립스로 통합되고 있다. 이클립스는 단순한 개발툴이 아니고 솔류션을 위한 프레임웍 혹은 컨테이너 역할을 하고 있다. 간단한 기능의 유틸리티는 이클립스 플러그인으로 개발하면 너무 훌륭하게 다른 유틸리티들과 함께 사용할 있다.
이런한 모습은 구글폰 같은 핸드폰에서도 나타나고 있다. 

과거의 CBD개념은 분명 100%실패한 개념이 아니라 다른 개념으로 진화해갈 것이고 언제가는 다시한번 세상을 풍미하지 않을까 하는 생각을 해본다. 
그런데 우리는 너무도 쉽게 쫓아가다가 너무도 쉽게 버리고 있는것은 아닌가? 
다시한번 CBD에 대한 개념정리가 공론화 되기를 바라는 마음에서 이글을 써본다.

아키텍쳐가 처음에 의도했던 방향대로 제대로 설계되었는지를 검증하는 분석 방법론으로, 설계된 아키텍쳐가 시스템 성능, 가용성, 확정성 등과 같은 비기능 요구사항에 대한 항목에 대해 초기에 의도했던 품질 목표를 만족시키고 있는지 분석하고, 여러 가지 품질 목표가 상호간에 어떻게 작용하는지 파악하는 것이 주요 역할이다.

ATAM은 일반적인 아키텍쳐 분석 방법과 유사하지만, 특히 다음과 같은 점이 중요하다.

• “이해 당사자의 능동적이고 적극적인 참여”,
• “핵심 이해 당사자의 충분한 준비”,
• “아키텍쳐 디자인 이슈와 분석 모델에 대한 이해”,
• “비기능 요구사항에 대한 명확한 정리”

ATAM을 통해 비기능 요구사항에 대한 자세한 분석, 아키텍쳐의 결정사항에 대한 이해, 그리고 그 결정사항이 요구사항을 만족시킬 수 있는지를 분석할 수 있다.

아키텍쳐 평가의 목적은 설계된 아키텍쳐의 결함을 확인하고, 비기능 요구사항의 관점에서 평가하는 것이 목적이며 아키텍쳐의 잠재적인 위험 요소를 감지하는 도구 역할을 한다. 이 평가 절차는 소프트웨어 개발 주기의 초기 단계에서 수행할 수 있으며, 구현이 아닌 설계된 디자인을 평가하기 때문에 상대적으로 비용이 저렴하고 빠르다는 것이 장점이다.

또한 아키텍쳐의 중요성을 일깨우고 아키텍쳐와 관련된 산출물의 수준을 높이는 것과 함께 아키텍쳐 분석 시 위험요소, Trade-off 요소등에 대해 파악하고 향후 개선안을 도출하는 것이 이 평가의 중요한 목표이다.

ATAM Process

Present the ATAM

평가팀이 모든 이해 관계자에게 평가 절차에 대해서 설명하는 단계이다. 평가 자체에 대한 설명 및 평가를 진행하는 동안 지켜야 할 여러 가지 규칙에 대해서 설명한다. 참여자에게 평가를 통해 얻을 수 있는 기대사항 등을 질의하며, 평가팀 멤버의 역할 및 다른 참여자의 역할에 대해 설명한다. 평가가 진행되는 동안 생성되는 유틸리티 트리, 시나리오, 아키텍쳐 접근 방법, 아키텍쳐 분석을 위한 기술 및 위험요소, Trade-off 목록에 대해서 자세히 설명하여 적극적인 참여를 유도한다.

Present the Business Drivers

프로젝트의 PM이 비즈니스 관점에서 평가팀에게 시스템에 대해서 설명하는 단계이며 다음의 사항을 위주로 설명한다.

가장 중요한 기능적 요구사항?????

기술적, 관리적, 정치적 제약사항

비즈니스 목표

중요한 이해관계자

품질 목표를 만족시키기 위한 아키텍쳐의 중요사항 평가팀은 비즈니스 드라이버 소개를 듣고 난 후 평가될 시스템의 범위를 정하고, 언급된 이해 관계자, 중요 품질 목표, 제약사항 등을 이해하고 목록을 작성한다.

Present the Architecture

아키텍트가 평가팀에게 아키텍쳐에 관해서 가능한 자세하게 설명하는 단계이다.

OS, 하드웨어, 미들웨어 등 이미 결정된 기술적인 제약사항

연동해서 사용해야 하는 다른 시스템

품질 요소를 만족시키기 위해 사용한 아키텍쳐 접근 방법

절차 기록자는 아키텍트가 설명할 때 중요 부분을 기록한다.

평가팀은 소개된 아키텍쳐 접근 방법, 잠재 위험요소, 추가적인 이해 관계자의 역할 등을 이해한다.

Identity the Architectural Approaches

[Present the Architecture]에서 소개된 아키텍쳐 고유의 접근 방법과 아키텍쳐 스타일을 파악하는 단계이다.

아키텍쳐 접근방법을 확인하는 방법으로는 S/W 아키텍트에게 질의할 수도 있으며 각각의 평가팀 멤버에게서 투표로써 접근방법을 조사할 수도 있다.

시나리오 기록자는 파악된 아키텍쳐 접근 방법을 기록한다 .

Generate the Quality Attribute Utility Tree

평가팀, 아키텍쳐 팀, 프로젝트 매니저 등이 협력하여 유틸리티 트리를 작성하는 단계이다.

이 단계에서 만들어진 유틸리티 트리는 이후의 평가 스텝에서 가이드 역할을 하며 분석의 목표를 구체화하는 효과를 기대할 수 있다.

유틸리티 트리를 통해 평가팀이 아키텍쳐의 어느 부분에 집중해야 할 지 등을 파악하고 평가의 범위를 결정하는 데 도움이 된다.

유틸리티 트리를 생성하는 절차

1. 루트에 “유틸리티”를 할당한다.
2. 루트의 하위 노드인 레벨2에 시스템의 품질요소를 할당.(예: Performance, Maintainability 등)
3. 레벨2 노드를 정제하여 레벨3 노드를 생성한다.
4. 레벨4 노드로서 품질 시나리오를 생성한다.
5. H/M/L 단위를 사용하여 시나리오의 중요도를 선정한다.
6. H에 할당된 시나리오에 대해 그 시나리오를 수행하기가 얼마나 어려운지 아키텍트에게 질의한다.
7. 품질요구 사항과 트리에서 나타난 중요 품질 요소 차이를 확인한다.
8. 유틸리티 트리를 기록한다 .

Analyze the Architectural Approaches

유틸리티 트리를 통해 평가 범위를 결정한 후, 아키텍쳐 접근 방법과 결정사항을 평가하는 단계로 아키텍쳐의 중요한 부분을 알아낸다.

이 단계의 가장 중요한 결과물은 Risk, Sensitivity point, Trade-off 등이며, 이들을 유틸리티 트리의 시나리오와 연계하여 품질요소에 대해 평가한다.

Brainstorm and Prioritize Scenarios

전체 이해 관계자로부터 시나리오를 생성하는 단계이다. 이 시나리오는 전체 이해관계자가 참여하는 투표 프로세스를 통해 우선순위가 정해진다.

유틸리티 트리는 시나리오를 생성하기 위한 하향식 메커니즘을 제공하는 반면에, 시나리오 Brainstorming은 상향식 접근법으로 시나리오를 생성하는 것이다.

평가 리더는 이해 관계자가 차례로 시나리오에 대해 말할 수 있도록 라운드로빈 방식으로 진행시킨다.

시나리오 기록자는 Brainstorming 결과를 기록하여 전 참여자가 볼 수 있도록 게시한다.

참여자는 게시된 시나리오 결과에 대해 토론하여 합치거나 삭제하여 시나리오를 정제한다.

시나리오가 결정된 후 투표를 실시한다.

결정된 시나리오의 수의 30%의 투표권을 할당한다. 
예를 들면 시나리오의 개수가 20 개라면 각각의 참여자가 투표수는 여섯 표씩 투표할 수 있다. 투표 결과로 높은 우선순위의 시나리오는 다음 스텝에서 분석 대상이 된다

상위에 랭크된 시나리오 사례

시나리오 별 관련 품질속성

Analyze the Architectural Approaches

태스크2에서 선정된 높은 우선순위의 시나리오를 분석한다. 부가적인 아키텍쳐 접근 방법, 위험 요소, 민감 요소 등을 찾아낸다 .

Present the Results

스텝 1~2 를 통해 수행한 평가 결과에 대해 최종 보고서를 작성한다

Two Faces of the ATAM

SAAM은 단순한 방법론이다. 특히 아키텍쳐 평가 경험이 없는 경우에 적용하기 적합하다.

아키텍쳐에 대한 modifiability나 functionality를 평가하는 목적이라면 ATAM보다 유용하다.

만약 S/W아키텍쳐와 infra아키텍쳐가 별도의 조직에 의해 유지되는 경우에 ATAM을 적용하게 되면 이해관계가 충돌하거나 오히려 평가의 본래 목적을 달성하지 못할 수 있다.이런 상황에서 Application Framework이나 공통 모듈을 집중적으로 검증하고자 한다면 SAAM은 적합한 방법론이라 할 수 있다.

SAAM은 변화에 대한 아키텍쳐의 준비/고려 상태를 평가하기 때문에 정량화된 평가 결과를 도출하는데 어려움이 있을 수 있다. 다만 다양한 경험을 가진 전문가들의 의견을 하나의 시나리오를 기준으로 판단해봄으로써 향후 방향성을 설정하는데 의미 있는 결과를 얻을 수 있다.

SAAM을 통해서 프로젝트는 다양한 변경요구가 프로젝트에 미치는 영향을 다양한 stakeholder와 공유할 수 있게 하는 장점이 있다.

ATAM에 비해 Critical 한 Quality(ex 성능)를 다루지 않음으로써 보다 안전하게 적용할 수 있다.

Develop Scenarios

• 시스템이 지원해야 하는 모든 기능성에 대해서 도출한다.
• 시나리오 도출에 있어 다음을 고려한다.
  • 시스템의 주요 사용
  • 시스템의 사용자
  • 미래의 변경 가능성
  • 시스템이 지원해야 하는 Qualities
• 시나리오는 Brain storming을 통해서 추출된다. 다양한 관점의 관련 당사자들에 의해 시나리오는 도출될 것이며 경우에 따라서는 동일한 시나리오가 여러 사람에 의해 제기될 수도 있다. 또는 동일한 문제에 관련 있는 다른 관점의 시나리오들이 작성될 수도 있다.
• 시나리오는 몇 번의 Iteration을 통해서 도출될 수 있다.

Describe the Architecture(s)

후보 아키텍쳐나 아키텍쳐는 반드시 분석에 참여하는 사람들이 이해 가능한 표기법으로 기술되어야 한다.

아키텍쳐 Description은 시스템 컴퓨팅환경, data 컴포넌트, 그리고 그와 관련된 Connection을 포함해야 한다.

The development of scenarios and the description of architecture usually drive each other.

description of architecture는 시나리오에 관련한 아키텍쳐 결정을 관련 당사자들에게 알려주는데, 반면에 시나리오는 아키텍쳐에 대한 요구 사항을 반영하고 있다.

Classify and Prioritize the Scenarios

시나리오는 크게 direct scenario와 indirect scenario로 구분되어 진다.

Direct시나리오는 아키텍쳐 디자인 단계에서 이미 고려된 요구 사항들 이다. 따라서 SAAM을 통해서 관련 당사자들은 자신의 요구가 아키텍쳐에 어떻게 반영되었는지를 보다 잘 이해할 수 있다.

아키텍쳐를 수정 없이 반영되어 있는 시나리오를 direct 시나리오라 하고 현재의 아키텍쳐는 지원하지 않고 뭔가 수정이 일어나야만 지원되는 시나리오를 indirect 시나리오라고 한다.

Direct시나리오는 Use case와 유사하고 Indirect시나리오는 Change case와 유사하다.

시나리오는 중요한 순서로 정리되는데 이때 중요하다는 기준은 전적으로 관련 당사자들의 판단에 의존한다.

Individually Evaluate Indirect Scenarios

• 일단 시나리오가 선택되면 시나리오는 아키텍쳐 결정 사항에 멥핑된다.
  • Direct scenario인 경우 아키텍트는 시나리오가 아키텍쳐에 의해 어떻게 실행되는지를 보인다.
  • Indirect scenario인 경우 아키텍트는 시나리오를 위해 아키텍쳐를 어떻게 변경해야 하는지를 제시한다 ? SAAM
• Review에 참가하는 사람들은 아키텍쳐의 구조와 각 컴포넌트의 상호 작용에 대해 보다 깊이 이해하게 된다.
• 모든 indirect scenario를 위해 아키텍쳐 변경에 대한 비용이 추정되어야 한다.
• 아키텍쳐의 변경이라 함은 새로운 Component혹은 Connect 추가나 기존 Component/Connect의 변경을 의미한다.
• 본 타스크가 끝나면 모든 시나리오에 대해 direct/indirect구분이 되어야 하고 indirect 시나리오에 대한 아키텍쳐 변경의 비용이 리스트업 되어야 한다.

Assess Scenarios Interactions

• 둘 이상의 indirect시나리오를 위해 하나의 컴포넌트 변경을 수반할 때 그 컴포넌트에서 시나리오가 interact한다라고 말한다.
• 시나리오 interaction이 중요한 이유
  • Product design에서 기능성 배치에 문제가 있음을 의미할 수 있고( poor separation of concerns)
  • 시나리오 interaction은 아키텍쳐의 structural decomposition이 적절하게 이루어 지지 않았음을 암시한다.
• 만약 시나리오 interaction을 발견하고 해당 컴포넌트를 분할하여 interaction이 나타나지 않는다면 다시 Step2-Describe the Architecture(s)를 수행해야 한다.

Create the Overall Evaluation

마지막으로 시스템의 성공에 중요한 시나리오 순으로 가중치를 부여한다.

가중치는 주로 시나리오가 표현하는 비즈니스의 중요도와 상관관계를 갖는다.

가중치는 하나를 시스템을 위한 여러 아키텍쳐를 평가하는데 중요한 기준이 된다.

만약 여러 개의 아키텍쳐를 비교한다면 direct 시나리오 수를 평가하는 것도 가능하다 direct시나리오는 아키텍쳐를 수정하지 않고 수행 가능한 것들이기 때문에 아키텍쳐의 완성도를 판단하는데 도움을 줄 수 있다.

경우에 따라서 tabular summary를 만드는 것도 도움이 된다.

Sample Agenda for a SAAM

파일럿이란 향후 완성하고자 하는 시스템의 특성(비기능 요구사항 및 기능적 요구사항에 대한 아키텍쳐적 결정)을 갖는 초기의 모형시스템을 만들어 고객의 요구가 적절히 반영되었는지를 파악하기 위한 과정이다. 
이것은 아키텍트의 결정이 주요 품질 요소들을 충족하는지를 실증적으로 검토하기 위한 과정으로 고객의 만족도를 높일 수 있고 프로젝트 관리자는 개발 생산성에 대한 확신을 얻을 수 있으며, 개발자는 새로운 아키텍쳐를 학습할 수 있는 기회를 갖게 된다.
파일럿 과정에서 누락된 고객의 요구사항이나 고객의 요구에 대한 잘못된 반영이 발견되면 과감히 문제가 시작된 곳으로 복귀(Feedback)시켜 문제를 해결해야 한다.

파일럿의 목적으로는 사용자와 개발자 사이에 신속한 피드백을 제공하고 상호간 의견을 명확하게 해주어 추상적인 생각의 차이를 운영 가능한 모형시스템을 통해 사용자의 요구 사항을 충분히 만족할 수 있도록 하는데 그 목적이 있다. 

1. 프로토타이핑
1.1 특성
프로토타이핑이란 최종 시스템이 어떻게 동작하는 지를 보여 주는 것으로, 문서로 된것이 아니라 실제적인 물리적인 모델을 말한다. 다시 말해서 빠른 시간내에 개발된 미완성 시스템인 것이다.

1.2 사용효과
프로토타이핑은 소프트웨어의 생산성 및 품질을 향상시켜주고 개발 또는 유지보수의 비용을 절감시켜 준다. 또 개발 초기부터 사용자를 참여시키기 때문에 사용자 만족도를 제고시키고 갑작스러운 변경 요구들의 부작용도 최소화 시킬수 있다.  구체적인 사용효과로는 아래와 같다.
1) 소프트웨어 생산성 향상
소프트웨어 생산성이 낮은 이유 중의 하나는 시스템 분석의 불완전성, 부정확성에서 기인한 유지 보수 필요성 때문이다. 프로토타이핑이 개발 기간은 단축시켜 주지 못하더라도 분석을 보다 치밀하게 할 수 있게 함으로 개발 생산성을 향상 시킬수는 있다.

2) 소프트웨어 품질보증
프로토타이핑은 사용자의 충족도를 기본 목표로 하여 탄생된 기술이므로 품질 보증 기법으로 사용될 수 있다. 왜냐하면 프로토타이핑이 오류를 감소시킬 것이기 때문이다. 또 시작부터 사용자의 참여를 중시하기 때문에 품질 보증의 개념이 깊숙이 박혀있다.

3) 개발과 유지 보수비용 절감
요구 분석의 정확성은 개발의 효율성을 높이고 유지 보수 필요성을 낮게 만들어 전체적으로 비용 절감 효과를 가져온다.

4) 사용자의 만족도 재고
시스템 오류의 대부분은(60 ~ 80%) 부정확한 요구 분석에서 기인한다. 잘 알려진 구조적 개발 방법들을 사용해도 사용자는 개발 지연과 품질 미흡에 불평을 하기 십상이다. 그러나 프로토타이핑의 WYSIWYG 의사소통방법과 사용자 참여 환경은 사용자의 기대를 충족시키는 효과를 가져온다.

5) 사용자 요구의 수용
사용자의 요구는 시스템에 대한 이해도가 높아지면서 혹은 상상했던 것을 실제 접하면서 변하기 마련이다. 개발자는 이러한 사용자의 애매 모호함과 심정의 변화에 불만 이겠지만 이것은 현실일 수밖에 업다. 따라서 개발자는 생명 주기의 시험 단계에서 크나큰 고충을 겪곤한다. 프로토타이핑은 개발 과정에 사용자의 참여를 유도하고 변할 수밖에 없는 많은 요구들이 생명 주기의 첫 단계에서 수용될 수 있는 기회를 부여하기 때문에 시험 단계에서의 고통을 크게 절감시킬수 있다.

6) 소프트웨어 유지 보수요구의 평가
현업 부서의 소프트웨어 개발 및 개선 요구는 흔히 알려진 것보다는 훨씬 많다. 전산 부서의 현실적인 한계 때문에 변경, 추가 요구가 절제되고 있을 뿐이다. 프로토타이핑은 이와 같은 방대한 유지 보수 요구의 타당성 조사 혹은 설득용 도구로 활용될 수 있다.

7) 기타
가) 의사소통을 원할히 한다.
나) 프로젝트 관리를 쉽게하고, 사용자 훈련 시간을 줄인다.
다) 유지 보수 노력을 줄여준다. 즉 개발 초기에 만족감을 준다.

2. 프로토타이핑의 개발단계
아래의 내용은 프로토타이핑을 위한 소프트웨어 개발단계를 기술한 것이다.

2.1 계획수립
시스템에 관한 기초적인 이해를 토대로 프로토타이핑 개발방식이 선택되면 계획이 수립되어야 한다. 계획단계에서는 다음과 같은 내용을 포함한다.
1) 프로토타이핑 방식의 타당성
프로토타이핑 프로젝트가 필요한 이유, 기대효과 등을 설명한다.

2) 목표 
달성하고자 하는 프로젝트의 목표를 기술한다.

3) 작업범위
프로젝트 기간동안 수행할 작업과 인력 소요정도, 작업의 한계를 명확히 하고 무슨 기법과 도구들이 활용될 것인지 밝힌다.

4) 사용자의 책임
사용자가 수행해야 하는 작업과 정보 제공의 책임을 기술한다.

5) 산출물
최종 산출물 즉, 프로토타이핑, 하드웨어 구성, 요구 분석서, 설계서, 그리고 사용자 지침서 등이 모두 프로토타이핑의 산출물에 속한다.

6) 일정표
상세한 일정 계획을 도표를 이용하여 그린다.

2.2 요구분석 및 설계
프로토타이핑을 설계하기 위해서는 먼저 환경 분석을 한후, 개발방법론에 따라 여러가지 도표(Diagram-자료 흐름도, E-R 도표 및 제어 흐름도) 을 차례로 작성한다.
OMT의 객체지향방법론을 사용할 경우에는 아래의 Diagram이 아닌 통합 표준 객체 지향 방법론인 UML(Unified Modeling Language)방법론에 따라 여러가지의 다른 Diagram이 생성된다.
1) 환경분석
프로토타이핑이 시작되면 시스템과 관련된 사용자 및 조직들이 시스템과 무슨 인터페이스를 가질 것인가 파악해 보는 것부터 시작한다.

2) 자료 흐름도 작성
사용자 그룹들과 함께 자료 흐름도(DFD)를 작성하여 시스템의 전체 흐름을 우선 파악한다.

3) ERD 작성
데이터베이스의 구성을 위해 E-R 도표를 작성한다.

4) 제어 흐름도 작성
시스템의 구조나 제어 흐름도를 그려 시스템의 단계적 활용도를 파악한다.

2.3 구현
프로토타이핑을 하려면 프로토타이핑 도구 또는 이러한 기능을 갖는 CASE 도구가 필요하다. 따라서 4세대 언어 기능(4GL)을 갖춘 개발도구와 관계형 DBMS가 있어야 한다.
1) 데이타베이스 설계 및 구축
객체간 관계를 설정하고 관계형 DBMS의 정규화된 테이블을 모형화한다.

2) 사용자 인터페이스 구현
요구 분석 및 설계 단계에서 설계되었던 제어 흐름도에 따라 개발한다. 또한 메뉴 상의 특정 항목이 선택 되었을때 무슨 화면을 띄우고 또한 무슨 프로시저를 불러 기능을 수행할 것인지를 4GL툴을 이용해 개발한다.

2.4 프로토타입 데모
사용자 집단의 정확한 요구를 파악하기 위해서 데모를 수행한다. 이것을 통해 시스템에 대한 사용자의 이해를 돕고, 새로운 의견을 청취해서 본격적인 설계를 할 수 있는 분석자료로 사용한다.

2.5 프로토타입의 지속적인 발전과 사용자의 승인
기존의 프로토타이핑은 새로운 요구나 변경 요청이 있을 경우에 앞서 설명된 개발주기(SDLC)에 따라 다시 추가적인 요구 분석 및 설계, 개발과정을 반복하며 발전시킬수 있다. 그러기 위해서는 사용자의 승인을 필요로 한다. 단 기능 요구 충족도에 국한된 승인만을 얻고 본격적인 상세 설계에 착수한다.

2.6 상세 설계 및 개발
프로토타이핑을 할때 설계된 내용들을 설계의 원칙을 따져가며 다시 검토하고 시스템 전체를 위한 상세 설계를 수행한다. 그리고 이를 구현시켜 완벽한 시스템이 되도록 한다.

2.7 성능조율(System Tunning)
성능 조율이란 개발된 프로토타입에 부하 시험을 가하여 신뢰성을 향상 시키고 데이터베이스의 구조를 최적화 시켜 효율성을 높이는 작업이다. 또한 시스템의 요구가 필요한 경우 변경을 가하고, 관계형 DBMS의 성능강화를 위해 불필요한 데이터는 다른 곳으로 옮기거나 압축시켜 저장하는 등의 작업도 수행한다.

2.8 품질평가
개발자에 의해 시스템으로 제작되는 과정에서 품질에 관한 평가를 받아야 한다. 일반적인 시스템 인수 시험제도가 이용될 수 있다. 또, 이용자와 함께 개발되는 시스템이므로 프로젝트 계획에 따라 점검 목록을 만들어 활용하는 것도 가능하다.

2.9 유지보수
사용자와 함께 개발된 시스템이므로 유지 보수의 요구가 줄어들지만, 새로운 기능의 추가나 다른 하드웨어로의 이식이 요구될 경우  프로토타이핑의 주기를 다시 수행함으로써 효율적인 유지 보수를 할수 있다.

 

무엇을 재사용하면 효과가 좋을까? 
아래의 도표가 현재 개발중인 시스템과 유사하지 않을 수 있다. 하지만 재사용의 효과에 대한 정도는 고민해 볼 필요가 있다.

 
 

Interaction Mode
크게 4가지 방식으로 정리할 수 있다. 그중에서 Bus방식과 Coordinated 방식이 유사하다
Bus방식과 Coordinated방식의 차이는 정보의 전달에 참여하는 방식에 따라 달라진다. Bus는 정보 전달에 있어 수동적인 역할만을 수행하지만 Coordinator는 자신이 Subject시스템으로 부터 데이터를 가져와 Target 시스템으로 전달하는 능동적 역할을 수행하게 된다.
예를 들어 JSP<->Servlet<->EJB 형태에서 servlet의 역할은 coordinator의 역할을 하고 있다.

 

Simple formatting validation
이것은 일반적으로 특정한 사용자 인터페이스에서 수행된다. 예를 들어 문자열입력을 위해 mask를 사용하여 숫자만을 입력 받는다든지 혹은 특별한 ID(XXX999포맷)를 입력받는 등의 입력 문자열의 문자 형태의 올바름을 검사한다.

Datatype validation
데이터에 내부적인 제약이 추가되는 경우이다. 15라는 값이 월에 입력되면 잘못된 값이다. 또는 체크값을 갖는 데이터의 경우 특히 주민번호와 같이 각 자리값의 로직적 판단이 필요한 Validation이 이에 해당한다.

System-parameter-dependent validation
설치된 시스템의 상황에 따라 달라지는 경우이다. 예를 들어 날짜의 경우 설치된 환경이 DD-MM-YYYY인경우에는 그에 맞게 검사되어야 한다. 
또한 이런 타입의 Validation에는 business code validation이 포함된다.  예를 들어 코드 테이블에 등록된 코드만을 허용해야 하는 경우의 validation을 의미한다 남녀구분, 지역구분, 통화구분코드 등이다. OLTP업무의 20~25%는 이러한 업무로 알려져 있다.

Functional validation
일반적으로 다른 비즈니스 컴포넌트나 일부 Database의 Data를 Access해서 Validation을 수행하는 경우이다. 예를 들어 계좌번호가 맞는지 혹은 해당 ID의 권한이 있는지 등을 검사하는 것을 의미한다.

Functional decomposition vs Entity-based decomposition
Functional decomposition는 시스템이 제공해야하는 기능을 기준으로 분할 하는 것이다. 특히 3GL (C,Pascal)로 구현하는 시스템에서 주로 사용되는 방식이다.
반면에 Entity-based decomposition은 주로 객체지향 언어에서 사용되는데 시스템에서 사용되어야 하는 Entity를 기준으로 분할하는 방식이다.비즈니스는 분석한다는 것은 주로 이두 개의 decomposition을 기준으로 수행된다.

Problem-domain-based decomposition vs Solution-domain-based decomposition
만약 시스템을 3Tier 구조로 가져가겠다라고 결정하였을때 이분할은 Solution-domain-based decomposition이다. 시스템에서 처리하고자하는 기능을 역할 분할하여 배치하는 것이다. 반대로 컴파일러 프로그램 처럼 어휘분석 -> 구문분석 -> 기계코드 생성 과 같이 해결해야 하는 문제를 기준으로 분할 하는 것을 Problem-domain 중심적인 분할이다.
S/W아키텍쳐가 설계될때 주로 이두개의 관점을 통해 아키텍쳐를 수립하게되는데 Tier나 Layer를 결정하는것을 Solution-based decompostition에 해당하고 Log나 Exception, Configuration등의 문제를 정리하는 것을 Problem-domain decomposition을 통해서 도출하게된다. 전자는 개념적 아키텍쳐가 되고 후자는 메커니즘/전략으로써 정리된다. 
또한 Problem-domain은 추적성이 떨어지는 문제가 있다 예를 들어 log, config와 같은 문제들은 이전에 특정한 요구에 기반하지 않고 컴퓨터 시스템이라는 특수성에 의해 도출되는 경우가 많아 주의를 요하는 경우가 많다.
 

 

Inheritance
Assuming that the component is implemented as aclass in an OO language, inheritance  can be used as a white-box technique to specialize the component for its context. Using inheriance, the component (re)user can define a subclass and add the application-specific behaviour to the component behaviour. Depending on the OO language that was used to implement the component, different mechanisms may be available to control the specialization of component behaviour. By defining operations as abstract, the component developer can require the component user to extend those operations. Similary, by defining operations as final, the component developer can block the component user to extend behaviour that would potentially lead to inconsistencies. Inheritance has a number of associated disadvantages, especially due to the fact that forms a logical entity is divided over multiple components. This may, among others, complicate the understandability and testing of components

Extensions
An extension is a variation point where the component user provides one out of several variants of some behaviour. The strategy design pattern is a typical example of using extensions. The underlying idea is to factor out functionality that may vary form stable functionality and to model the variable functionality as an independent entity. The different instances of variable functionality are implemented as variants and the component user can either select an existing variant or develop a new variant

Configuration
A third approach to handling variability is to include all variants at all variantion points into the component and to provide an interface to the component user. This interface allows the user to set parameters that select particular variants at the variantion points. Through the use of , for instance, procedure parameters, components can even be configured for invoking component.

Template instantiation
Components, at times, need to be configured with application-specific types. A typical example is list-handling or queue component that needs to be configured with the type of element that is to be stored in the use of templates, I.e. component definitions that can be instantiated for particular types. Templates are particularly useful for performing type adaptation.

Generation
The final type of variability mechanism to be discussed here is the notion of a component generator. The typical use of this approach is that the component user prepares a specification in some language, e.g a domain-specific or component-specific language. This specification is taken as input by a generator, or high-level compiler, that translates the specification into, generally, a source-code-level component that can be incorporated into the product ar pplication that component user is concerned with. Typcal examples of this approach can be found in graphical user interfaces where either a graphical or textual specification is used to generate a source-code component that implements the desired functionality 

Business Component에서 외부 Logic과 2가지 관점에서 Dependency를 갖는다. 구조적 의존성은 컴파일 타임에 검사가 되기 때문에 의외로 문제가 되지 않으나 기능적 의존성이 보다 어려운 문제이다 따라서 Dependency관리 전략이라 함은 이러한 기능적 의존성을 간결하게 하여 보다 일관된 Component를 구성하는데 목적이 있다.

Structural Dependency(Technical Dependency)
구조적이라 함은 Compile Time의 Dependency를 의미한다. 호출되는 Method명과 인터페이스의 Method명이 일치해야 한다.

Functional Dependency 
기능적인 의존관계 즉 Client가 원하는 행위를 수행해야 한다는 것이다. 만약 100볼트 전자 제품을 200볼트의 소켓에 연결하려고 하면 소켓의 모양이 않 맞다 그래서 중간에 컨버터를 꽂아서 연결한다면 과연 전자 제품이 정상적으로 동작할까? 절대 아니다. 전자제품은 바로 고장 날 것이다. 마찬가지로 Structural Dependency만을 맞춘다고 Component가 동작하는 것이 아니다
그러나 기능적 의존성은 그 자체로 비즈니스를 대변하기 때문에 정형화 한다는 것 자체가 상당히 어려움이 있고 이것은 CBD를 위한 하나의 중요한 기술 영역이라 볼 수 있다.
이러한 기능적 의존관계를 효과적으로 관리하기 위한 것은 분석적인 영역이라고 할 수 있는데 다만 아키텍쳐에서는 컴포넌트의 인터페이스가 최대한 기능적 요구를 대변할 수 있도록 만들어야 한다. 마치 100V소켓과 200V소켓의 모양이 다른 것과 같은 이치이다.