Rational 의 소프트웨어 개발 방법론

Rational 의 소프트웨어 개발 방법론인 Rational Unified Process 에서는 반복적인 개발

방법을 제안한다. 소프트웨어의 개발은 여러 번의 반복(Iteration)을 거치며 각각의 반복은

요구사항 분석, 분석 & 설계, 구현, 및 테스트 & 평가 과정을 포함하고 있어 자체로서도 하나의

개발주기를 이룬다. 이러한 반복적인 개발 방법에서는 반복마다 실행 가능한 릴리즈가 산출되고

이는 반복이 거듭될수록 향상되어 결국 최종 시스템으로 발전된다.

전통적인 waterfall 프로세스와 비교했을 때 반복적인 개발 방법이 갖는 장점은 다음과 같다.

초기에 위험요소를 줄일 수 있다.

변경에 대한 관리가 용이하다.

보다 높은 수준의 재사용이 가능하다.

프로세스가 진행됨에 따라 프로젝트 팀원의 기술이 향상된다.

전반적으로 높은 품질을 얻을 수 있다.

본 제안서에서는 Rational 의 소프트웨어 개발 방법론을 간략히 설명하고 Rational 의 방법론과

함께 적용할 수 있는 도구들에 대해 설명한다. 먼저 기본적인 용어에 대해 설명한 다음 방법론을

설명한다. 이때 방법론에 적용할 수 있는 도구들을 함께 설명한다. 그리고 마지막으로 방법론에

적용 가능한 도구들을 요약 정리한다.

1. 래쇼날의 개발 방법론(Rational Unified Process) 이해를 위한 기본 개념

방법론(프로세스)은 소프트웨어 개발 과정에서 누가 언제, 어떻게, 무엇을 수행해야 하는가를

기술한다. Rational Unified Process 는 다음과 같은 4 가지 주요 구성요소로 표현될 수 있다.

작업자(Workers) : ‘누가(who)’에 해당

액티비티(Activities) : ‘어떻게(how)’에 해당

산출물(Artifacts) : ‘무엇을(what)’에 해당

웍플로우(Workflows) : ‘언제(when)’에 해당

작업자(worker)라는 용어는 개인이나 그룹(또는 팀)의 행위(behavior)와 책임(responsibility)을

정의한다. 행위는 작업자가 수행하는 액티비티(activity)로 표현되며 작업자는 상관관계를 가질 수

있는 일련의 액티비티와 연관되어 있다. 액티비티들간에 상관관계를 갖는다는 말은 특정

액티비티들이 한 사람에 의해서 수행될 때 성취도가 높아질 수 있다는 것을 의미한다. 각각의

작업자의 책임은 일반적으로 작업자가 생성하고, 변경하고 통제하는 산출물(artifact)로 표현될 수

Page : 1

있다.

1.1 액티비티, 산출물, 그리고 작업자

U se-Case DesignU se-Case AnalysisD esigner

U se C ase Realiza tion

Worker Activities

Artifact responsible for

작업자(Workers), 액티비티(activities)와 산출물(artifacts)

작업자(Worker)

작업자(worker)는 개인이나 그룹의 행위와 책임을 의미한다. 작업자는 개인이 착용할 수 있는

“모자”와 같은 개념으로 생각할 수 있다. 개인이 상황에 따라 여러 다른 모자를 착용할 수 있는

것처럼 개인(또는 그룹)은 경우에 따라 여러 다른 작업자가 될 수 있다. 이러한 비유는 작업자라는

개념을 이해하는 데 큰 도움이 될 것이다. Rational Unified Process 에서는 작업자는 주어진 일을

수행해야 하는 역할(role)을 의미한다. 또한 작업자는 하나 이상의 역할을 수행하는 것 외에도 특정

산출물의 소유자(owner)가 된다. 작업자의 예로는 다음과 같은 것이 있다.

시스템 분석가(System Analyst) : 시스템 분석가의 역할을 하는 사람은 시스템의 범위를

정의하고 시스템의 기능의 초안을 작성한다. 또한 이를 통해 요구사항을 추출하고 유스

케이스를 모델링하는 작업을 주도적으로 수행하며 때로는 조정자의 역할을 한다.

설계자(Designer) : 설계자는 클래스의 책임(responsibilities), 연산(operations), 속성(attributes)

과 클래스간의 관계(relationships)를 정의하고 구현 환경에서 어떻게 적용될 것인가를

결정한다.

테스트 설계자(Test Designer) : 테스트 설계자는 테스트의 계획, 설계, 구현 및 평가를

담당한다.

Page : 2

Resource Worker Activities

Paul

M ary

Joe

Sylvia

S tefan

Designer

Use-C ase A uthor

Use-C ase D esigner

Design Review er

Architect

O bject D esign...

Deta il a U se C ase...

Use-C ase D esign...

Review the D esign...

Arch itectura l Ana lysisArch itectura l Design...

팀원과 작업자

액티비티(Activity)

특정 작업자의 액티비티(activity)는 작업자의 역할에 따라 수행해야 하는 단위 업무를 말한다.

각각의 액티비티는 명확한 목적을 갖는다. 예를 들어 모델이나 클래스 또는 계획과 같은 특정

산출물을 생성하거나 수정하는 것이 일반적으로 액티비티의 목적이 될 수 있다. 모든 액티비티는

알맞은 작업자에게 배정된다.

액티비티는 일반적으로 몇시간에서 몇일정도가 소요되고, 보통 하나의 작업자에 의해 수행되며,

하나 혹은 적은 수의 산출물에 영향을 미친다.

액티비티의 예

반복 계획(Plan an iteration) : 프로젝트 관리자라는 작업자에 의해 수행

유스 케이스와 액터를 추출(Find use-cases and actors) :시스템 분석가라는 작업자에 의해

수행

설계 검토(Review the design) : 설계 검토 담당자라는 작업자에 의해 수행

성능 테스트 수행(Execute a performance test) : 성능 테스트 담당자라는 작업자에 의해 수행

산출물(Artifact)

산출물(artifact)은 프로세스에 의해 생성되고 수정되고 사용되는 정보의 단위이다. 산출물은

프로젝트에서 최종 제품을 개발하는 과정에서 생성되고 사용되는 형태를 갖는 산물을 말한다.

산출물은 작업자가 특정 액티비티를 수행할 때 입력으로 사용될 수 있으며 또한 액티비티 수행의

결과로 생성될 수 있다. 객체지향 설계 용어로 말하면, 액티비티는 특정 객체(작업자)에 대한

Page : 3

연산이라고 할 수 있고 산출물은 이러한 액티비티의 파라미터라고 할 수 있다.

산출물은 다음과 같이 다양한 형태일 수 있다.

유스 케이스 모델, 디자인 모델과 같은 모델

모델의 구성요소, 예를 들면 클래스, 유스 케이스, 서브시스템(subsystem)

비즈니스 케이스, 소프트웨어 아키텍쳐 문서와 같은 문서

소스 코드

실행 파일

1.2 웍플로우(Workflow)

작업자, 액티비티, 산출물의 단순한 나열만으로는 프로세스를 구성할 수 없다. 프로세스를

이루기 위해서는 가치있는 결과를 생성할 수 있게 하는 액티비티의 순서와 작업자간의

상호작용을 기술할 수 있어야 한다. 웍플로우(workflow)는 의미있는 결과를 생성하는 액티비티의

순서(sequence)를 말한다. UML 에서 웍플로우는 Sequence 다이어그램, Collaboration 다이어그램,

액티비티 다이어그램으로 표현된다.

Arch itect

U se-C ase Designer

D esigner

D esign Reviewer

Architectural Analysis

R eview theD esign

Review theAnalysis

R eview theArchitecture

Object D esignObject Analysis

U se-C ase D esignU se-C ase Analysis

Architectural Design Describe Concurrency Describe D istribution

앞의 그림은 웍플로우의 예이다. 항상 액티비티간의 모든 의존관계를 표현할 수 있는 것은

아니며 또한 모든 의존관계를 표현하는 것이 항상 유용한 것만은 아니라는 점에 주의해라. 때때로

액티비티들은 웍플로우에서 보여지는 것보다 더 밀접하게 관련되어 있을 수도 있다. 특히 두

액티비티가 같은 작업자 또는 같은 사람에 의해 수행될 때 밀접하게 관련될 수 있다.

Page : 4

1.3 핵심 웍플로우(Core workflows)

앞의 그림은 Rational Unified Process 의 구조를 나타낸다. 가로축은 시간의 흐름을 의미하고

세로축은 특정 시간대에서 수행해야 할 액티비티를 의미한다. 도표에서 가로축을 통해

소프트웨어 개발주기가 여러 번의 반복으로 이루어져 있는 것을 확인할 수 있고, 세로축에 있는 9

개의 웍플로우1가 반복이 진행됨에 따라 각기 얼마만큼의 비중으로 수행되어야 하는가를 확인할

수 있다.

그림에서와 같이 Rational Unified Process 에는 9 개의 핵심이 되는 웍플로우가 존재하는데

이러한 웍플로우는 작업자와 액티비티를 논리적인 관련성에 따라 분류한 것을 의미한다. 9 개의

핵심 웍플로우는 다시 6 개의 엔지니어링을 위한 웍플로우와 3 개의 지원을 위한 웍플로우로 나눌

수 있다. 엔지니어링을 위한 웍플로우에는 다음과 같은 것이 있다.

1. 비즈니스 모델링 웍플로우(Business Modeling workflow)

2. 요구사항 웍플로우(Requirements workflow)

3. 분석 & 설계 웍플로우(Analysis and design workflow)

4. 구현 웍플로우(Implementation workflow)

5. 테스트 웍플로우(Test workflow)

6. 배포 웍플로우(Deployment workflow)

3 개의 지원을 위한 웍플로우는 다음과 같다.

1. 프로젝트 관리 웍플로우(Project management workflow)

2. 형상 및 변경 관리 웍플로우(Configuration and change management workflow)

1 웍플로우는 액티비티들을 논리적인 관련성에 따라 분류한 것을 말한다

Page : 5

3. 환경 웍플로우(Environment workflow)

6 개의 엔지니어링을 위한 웍플로우의 명칭은 전통적인 waterfall 프로세스의 순차적인 단계를

연상시키지만 반복적인 프로세스(Iterative Process)에서 이러한 웍플로우는 개발주기동안 여러

차례 반복된다는 점에서 상이하다.2

Waterfall 프로세스

3 개의 지원 웍플로우는 말 그대로 개발 과정 중 6 개의 엔지니어링을 위한 웍플로우를 지원하는

역할을 한다. 프로젝트 관리 웍플로우는 개발 프로젝트를 계혹하고 관리하는 액티비티를

관장하고, 환경 웍플로우는 개발 환경을 정의하고 관리하는 액티비티를 관장한다. 형상 및 변경

관리 웍플로우는 다양한 개발 과정의 산출물을 형상관리하는 액티비티와 다양한 변경요청을

관리하는 액티비티를 관장한다.

실제 프로젝트를 위한 웍플로우는 이러한 9 개의 핵심 웍플로우를 이용하여 구성되고,

프로젝트를 완성하기 위해 구성한 웍플로우를 여러 차례 반복하게 된다.

다음 장의 그림과 같이 프로젝트 개발 중 여러 번 반복이 수행될 수 있지만 각각의 반복마다

주안점은 조금씩 달라진다. 초기의 반복에서는 분석에 중점을 두며, 다음 번 반복에서는 점차 분석

&설계, 구현쪽에 중점을 두게 된다. 그리고 말기의 반복에서는 테스트와 배포에 중점을 두게 된다.

2 소프트웨어에 대한 요구사항은 고정되지 않고 항상 변화한다는 점과 또한 실제 구현 전에

완벽하게 소프트웨어를 설계하는 것은 사실상 불가능하는 점 때문에 Waterfall 프로세스와

같이 한번에 모든 개발을 끝내는 방법에 비해 반복적인 프로세스가 소프트웨어 개발에 보다

효과적이다.

Page : 6

반복적인 프로세스

아래 그림에서 각각의 반복에서 수행되는 액티비티들을 보다 구체적으로 볼 수 있다.

초기 반복에서의 액티비티

Page : 7

중기 반복에서의 액티비티

말기 반복에서의 액티비티

다음 절에서는 이들 9 개의 핵심 웍플로우 각각에 대해 자세히 설명한다.

Page : 8

2. 9 개의 핵심 웍플로우

2.1 프로젝트 관리 웍플로우

가) 목적

프로젝트 관리 웍플로우는 다음과 같은 세가지 주된 목표를 갖는다.

소프트웨어의 비중이 높은 프로젝트의 관리를 위한 프레임웍 제공

프로젝트를 계획하고, 인원 구성을 하고, 실행하고, 모니터링하는 데 사용할 수 있는 지침

(guideline) 제공

위험요소의 관리를 위한 프레임웍 제공

Rational Unified Process 에서의 프로젝트 관리 웍플로우가 프로젝트 관리에 관련된 모든 사항을

다루는 것은 아니다. 예를 들어 다음과 같은 사항은 다루지 않는다.

인적 자원의 관리 : 고용, 훈련…

예산의 관리

공급자와 고객과의 계약을 관리

반면에 프로젝트 관리 웍플로우는 반복적인 개발 프로세스에서 다음과 같은 사항에 중점을

둔다.

위험요소 관리

반복 계획

반복적인 프로젝트의 진행상황과 평가기준(metrics)을 모니터링

나) 작업자와 산출물

프로젝트 관리 웍플로우에서는 프로젝트 관리자(project manager)라는 하나의 작업자만이

존재한다. 프로젝트 관리 웍플로우의 주요 산출물에는 다음과 같은 것이 있다.

다음과 같은 산출물을 포함하는 소프트웨어 개발 계획(SDP : Software Development Plan)

- 위험요소 목록(Risk list)

- 프로젝트 계획(Project Plan)

- 측정 계획(Measurement plan)

비즈니스 케이스(Business Case)

반복 계획(Iteration Plan) : 반복마다 하나씩

반복 평가(Iteration Assessment)

기타 주기적인 상태 평가(Periodic status assessment)

Page : 9

소프트웨어 개발 계획에는 다른 작업자에 의해 작성되는 계획도 포함되어 있다. 예를 들어

다음과 같은 것들이 있다.

형상 관리자(configuration manager)라는 작업자에 의해 작성되는 형상 관리 계획

(Configuration Management Plan)

프로세스 엔지니어(Process Engineer)라는 작업자에 의해 작성되는 개발 케이스(development

case : 프로젝트에서 사용되는 프로세스)

다음 그림은 프로젝트 관리 웍플로우에서 작업자와 산출물의 관계를 보여준다.

Page : 10

다) 웍플로우

아래의 그림은 전형적인 프로젝트 관리를 위한 웍플로우를 보여준다.

라) 요약

프로젝트 관리 웍플로우는 상충되는 목적을 조정하고, 위험요소를 관리하고, 제한요인을

극복하는 데 유용하게 사용될 수 있다. 그리고 이를 통해 고객과 최종사용자에게 요구에

부합되는 제품을 성공적으로 제공할 수 있게 된다.

반복적인 프로세스에서 개발은 단계별 계획(phase plan)과 일련의 반복 계획(iteration plan)에

기반하여 수행되어야 한다.

위험요소는 계획 수립 시 사용하는 중요한 자료이다.

측정(Measurement)은 프로젝트를 통제하는 데 사용되는 핵심 기술이다.

단계별 계획을 수립할 때, 반드시 인적 자원과 일정과 프로젝트 범위에 대한 조정을 해야

한다.

반복의 범위를 정하는 기준은 단계별로 다를 수 있다.

2.2 비즈니스 모델링 웍플로우

가) 목적

비즈니스 모델링의 목표는 다음과 같다.

조직의 구조와 기능을 이해

고객과 최종 사용자, 개발자들이 조직에 대한 이해를 공유

조직을 지원하기위해 필요한 요구사항의 추출

이러한 목표를 달성하기 위해 비즈니스 웍플로우에서는 비즈니스 모델을 개발한다. 비즈니스

Page : 11

모델은 유스 케이스 모델과 비즈니스 객체 모델로 이루어진다.

Page : 12

나) 작업자와 산출물

비즈니스 모델링에 관련된 주요 작업자는 다음과 같다.

비즈니스 프로세스 분석가(Business Process Analyst) : 비즈니스 프로세스 분석가는 비즈니스

유스 케이스 모델링 작업을 주도적으로 수행하며 때로는 조정자의 역할을 한다. 예를 들어

비즈니스 프로세스 분석가는 비즈니스 액터와 비즈니스 유스 케이스를 도출하고 이들이

어떻게 상호 작용하는가에 대해 기술한다.

비즈니스 설계자(Business Designer) : 비즈니스 설계자는 비즈니스 유스 케이스의 웍플로우를

기술함으로써 전체 조직의 일부의 사양을 상세화한다. 비즈니스 설계자는 비즈니스 유스

케이스를 실현하기 위해 필요한 작업자(액터)와 엔티티(클래스)를 명시하고 비즈니스 유스

케이스의 행위를 명시된 비즈니스 엔티티에 분배한다. 비즈니스 설계자는 비즈니스

작업자와 비즈니스 엔티티의 책임(responsibility), 연산(operation), 속성(attribute), 관계

(relationship)를 정의하는 역할을 수행한다.

이외에 비즈니스 모델링에 관련된 기타 작업자는 다음과 같다.

이해당사자(Stakeholder)

비즈니스 검토 담당자(Business Reviewer)

비즈니스 모델링 웍플로우의 작업자와 산출물

비즈니스 모델링 웍플로우의 주요 산출물에는 다음과 같은 것이 있다.

Page : 13

비즈니스 유스 케이스 모델(Business use-case model) : 비즈니스 기능에 대한 모델로서

조직내의 역할과 산출물을 추출하는 데 사용된다.

비즈니스 객체 모델(Business object model) : 비즈니스 유스 케이스의 실현(realization)에 대해

기술하는 객체 모델

기타 산출물에는 다음과 같은 것이 있다.

보충 비즈니스 사양(Supplementary business specifications) : 비즈니스 유스 케이스 모델이나

비즈니스 객체 모델에 포함되지 않은 필요한 기타 정의를 제시하는 문서

용어집(glossary) : 비즈니스에서 사용되는 주요 용어를 정의

다) 웍플로우

앞의 그림은 전형적인 비즈니스 모델링 웍플로우이다. 웍플로우에서 비즈니스 프로세스

분석가는 주요 비즈니스 프로세스와 비즈니스에 관계된 당사자를 식별하고 이를 비즈니스 액터와

비즈니스 유스 케이스로 구성된 비즈니스 유스 케이스 모델로 작성한다. 이 과정에서 비즈니스

프로세스 분석가는 비즈니스에 관련된 주요 용어과 개념에 대한 정의를 추출한다.

한편 비즈니스 설계자는 비즈니스 유스 케이스를 구체화하여 조직에서 필요한 역할(role)과 책임

(responsibility)을 식별하고 프로세스의 산출물(deliverable)을 식별해 낸다. 또한 비즈니스 모델이

조직을 제대로 반영하고 있는가 검증할 다양한 부류의 사람들이 비즈니스 검토 담당자가 되어

되어 각기 특정 부분을 검토한다. 어떤 사람들은 상위 레벨의 비즈니스 유스 케이스의 기술을

검토하게 또 다른 사람들은 비즈니스 작업자와 비즈니스 엔티티에 대해 검토한다.

Page : 14

라) 도구 지원

Rational Rose 는 UML 기반의 비즈니스 모델링 도구로서 앞서 언급한 비즈니스 모델링을

수행하는 데 필요한 모든 기능을 제공한다. Rational RequisitePro 는 모델로부터 문서의 관점에서

정보를 추출하여 모델의 구성요소간의 의존관계를 유지할 수 있게 한다. 또한 Rational SoDA 는

자동 문서화 툴로서 모델의 문서화를 지원한다.

마) 요약

비즈니스 모델링은 비즈니스의 구조와 동적인 특성을 이해하기 위해 필요하다. 또한 이는

관련된 사람들이 조직에 대한 이해를 공유할 수 있게 하기 위해, 또한 조직을 지원하기 위한

시스템의 요구사항을 추출하기 위해서도 필요하다.

비즈니스 모델링에는 다양한 소프트웨어 엔지니어링 기법이 적용되어 이용될 수 있다.

비즈니스 모델링에는 다양한 기법이 있다. 따라서 시스템의 특성과 프로젝트에 따라 알맞은

기법을 사용해야 한다.

소프트웨어 요구사항은 비즈니스 모델로부터 추출될 수 있다.

비즈니스 모델링은 Rational 사의 도구를 사용하여 효과적으로 수행할 수 있다.

2.3 요구사항 웍플로우

가) 목적

요구사항 웍플로우의 목표는 다음과 같다.

시스템이 무엇을 해야 하는가에 대한 고객과 사용자의 동의 획득

개발자에게 시스템의 요구사항에 대해 충분히 이해할 수 있게 함

시스템의 기능(functionality)을 정의

반복의 계획과 기술적인 내역(technical contents)을 위한 기초 제공

시스템을 개발하는 데 필요한 시간과 비용을 측정하기 위한 기초 제공

시스템의 사용자 인터페이스 정의

이와 같은 목표를 달성하기 이루기 위해서 요구사항 웍플로우는 시스템의 비전을 어떻게

정의할 것이며 비전으로부터 시스템의 상세 요구사항을 기술하는 유스 케이스 모델을 어떻게

만들 것인지에 대해 설명한다. 이외에도 요구사항 웍플로우는 시스템의 범위를 관리하는 방법과

변화하는 요구사항을 관리하는 방법을 정의하고 또한 사용자 인터페이스의 프로토타입을

정의하는 방법을 정의한다.

Page : 15

나) 작업자와 산출물

요구사항 웍플로우에서 작업자와 산출물의 관계

앞의 그림에서 볼 수 있는 것과 같이 요구사항 웍플로우의 주요 작업자와 산출물에는 다음과

같은 것이 있다.

주요 작업자

시스템 분석가(System Analyst) : 시스템 분석가의 역할을 하는 사람은 시스템의 범위를

정의하고 시스템의 기능의 초안을 작성한다. 그리고, 이를 통해 요구사항을 추출하고 유스

케이스를 모델링하는 작업을 주도적으로 수행하며 때로는 조정자의 역할을 한다.

유스 케이스 명세 담당자(Use-case specifier) : 유스 케이스 명세 담당자는 유스 케이스의

요구사항을 상세히 기술함으로써 시스템의 기능(전체 혹은 일부)을 구체적으로 명시한다.

아키텍트(Architect) : 요구사항 웍플로우에서 아키텍트는 아키텍쳐의 관점에서 중요한

유스케이스와 요구사항을 식별하고 정의하는 책임을 진다.

이외에도 다음과 같은 작업자들이 존재한다.

사용자 인터페이스 설계자(User-Interface Designer)

요구사항 검토 담당자(Requirement Reviewer)

Page : 16

요구사항 웍플로우의 주요 산출물에는 다음과 같은 것이 있다.

Stakehoder needs

비전 문서(Vision Document)

유스 케이스 모델(Use-Case Model)

보충 사양(Supplementary specification : 유스 케이스로 표현되지 않는 요구사항을 기술)

요구사항 속성(Requirement attributes) : 다양한 요구사항의 특징과 요구사항간의 의존관계를

정의

유스 케이스 Storyboard

사용자 인터페이스 프로토타입(User-Interface prototype)

경계 클래스(Boundary class) : 분석 모델에서 어떻게 사용자 인터페이스가 실현되는가를 보여

준다.

다) 웍플로우

앞의 그림은 요구사항 웍플로우 구성을 나타낸다. 웍플로우에서 시스템 분석가는 시스템이 어떤

기능을 제공해야 하는가를 식별(시스템의 범위를 식별)하고, 또한 성능과 같은 기능 외적인

요구사항을 식별한다. 그런 다음 시스템 분석가는 프로젝트의 비전을 작성한다. 비전은

프로젝트에 관련된 이해당사자의 입장에서 작성한 기능으로 표현되며 유스 케이스 모델의 초안을

Page : 17

개발하는 데 밑거름이 된다.

유스 케이스 명세 담당자에게는 유스 케이스와 보충 요구사항이 할당되며, 유스 케이스

명세자는 이를 상세화한다. 또한 이 과정에서 요구사항 웍플로우의 다른 산출물과 일관성을

유지해야 한다. 따라서 유스 케이스 명세 담당자는 독립적으로 일하지 않고 일반적으로 다른 유스

케이스 명세 담당자, 그리고 시스템 분석가와 의견을 교환하면서 작업한다.

사용자 인터페이스 설계자는 유스 케이스 명세 담당자가 작업할 때 시스템의 사용자 인터페이스

설계작업을 수행한다. 많은 경우에 이들 작업자들이 상호작용을 함으로써 상승(synergy) 효과를

낼 수 있다.

아키텍트는 주로 초기의 반복에 관련되어 있으며 시스템 분석가와 유스 케이스 명세 담당자와

공동으로 작업하여 아키텍쳐의 관점에서 중요한 유스 케이스의 무결성을 보장한다. 한편

요구사항 검토 담당자는 개발 팀이 요구사항을 올바르게 인지했는가를 검증한다.

라) 도구 지원

Rational RequisitePro 는 요구사항을 추출하고 추출한 요구사항을 문서와 데이터베이스로

체계화할 수 있게 하며, 요구사항의 범위와 변경에 대한 관리를 수행한다. 유스 케이스를 사용하는

경우에는 RequisitePro 를 이용하여 유스 케이스 중 문서로 표현할 수 있는 측면을 자유롭게 기술할

수 있다.

요구사항의 산출물(예를 들어 유스 케이스 모델, 유스 케이스 시나리오 등)을 비주얼 모델링하기

위해서는 Rational Rose 를 사용할 수 있다. 이때 RequisitePro 와 Rose 는 요구사항의 산출물과 설계

모델간의 일관성을 보장한다. 또한 Rational SoDA 는 문서를 자동으로 생성해 준다. SoDA 를

이용하여 필요한 문서의 Template 을 정의할 수 있으며, SoDA 는 Template 에 명시된 대로 알맞은

곳에서 정보를 추출하여 문서를 생성한다. SoDA 는 특히 여러 종류의 Rational 툴을 사용할 때

유용하게 쓰일 수 있다.

마) 요약

요구사항은 시스템이 만족시켜야 하는 조건(condition) 또는 능력(capacity)을 말한다.

일반적으로 프로젝트를 수행할 때에는 기능에 대한 요구사항, 성능과 같은 비기능적

요구사항 등 여러 가지 유형의 요구사항을 고려해야 한다.

Rational Unified Process 는 사용자 인터페이스 설계를 사용자 인터페이스를 비주얼하게

형상화하는 것으로 정의한다. 사용자 인터페이스 설계를 통해 다양한 사용편의성(usability)에

대한 요구사항을 다룰 수 있다.

기본적인 요구사항 웍플로우에서는 다양한 작업자가 문제를 분석하고, 이해당사자의 요구

(needs)를 도출해 내고, 시스템을 정의하고, 프로젝트의 범위를 관리하고, 변경된 요구사항을

관리하는 작업을 수행한다.

요구사항 추출과 관리는 Rational 사의 도구를 사용하여 효과적으로 수행할 수 있다.

Page : 18

2.4 분석 & 설계 웍플로우

가) 목적

분석 & 설계 웍플로우의 목표는 요구사항으로부터 시스템을 구현하는 방법을 기술하는 사양

(specification)을 추출하는 데 있다. 이를 위해서는 우선 요구사항을 이해하고 최적의 구현 전략을

선택함으로써 요구사항을 시스템 설계로 변환하여야 한다. 이해하기 쉽고 구축하기 쉽고

발전시키기 쉬운 시스템을 설계하기 위해서는 먼저 프로젝트의 초기단계에서 건실한 아키텍쳐를

설정해야 한다. 그런 다음 설계를 구현환경에 알맞게 수정하는 작업이 이루어져야 한다. 이

과정에서는 성능, 안정성, 확장성, 테스트 가능성 등에 대해 고려해야 한다.

나) 작업자와 산출물

분석 & 설계 웍플로우의 작업자와 산출물의 관계

분석 & 설계 웍플로우의 주요 작업자는 다음과 같다.

아키텍트(Architect) : 아키텍트는 프로젝트기간동안 기술적인 액티비티 및 산출물에 관련된

작업을 주도하고 또한 필요에 따라 조정하는 일을 담당한다. 아키텍트는 아키텍쳐의

관점에서 전체적인 구조를 설정한다. 다른 작업자와는 달리 아키텍트의 관점은 깊이보다는

넓이에 주안점을 둔다.

설계자(Designer) : 설계자는 클래스의 책임(responsibilities), 연산(operations), 속성(attributes)

과 클래스간의 관계(relationships)를 정의하고 구현 환경에서 어떻게 적용될 것인가를

결정한다. 이외에도 설계자는 패키지나 서브시스템(subsystem)을 설계할 책임을 갖는다.

Page : 19

이외에도 분석 & 설계 웍플로우에는 다음과 같은 작업자가 있을 수 있다.

데이터베이스 설계자(Database Designer) : 설계하는 시스템이 데이터베이스를 포함할 때

필요하다.

아키텍쳐 검토 담당자(Architect Reviewer) 및 설계 검토 담당자(Design Reviewer) : 분석 &

설계 웍플로우의 주요 산출물을 검토한다.

분석 & 설계 웍플로우의 주요 산출물에는 다음과 같은 것이 있다.

설계 모델(Design Model) : 구축할 시스템의 주요한 청사진

소프트웨어 아키텍쳐 문서(Software Architecture Document) : 시스템을 아키텍쳐의 관점에서

기술한 문서

다) 웍플로우

앞의 그림은 전형적인 분석 & 설계 웍플로우이다. 분석 & 설계 웍플로우에는 두 개의 상세

웍플로우가 상호 관련되어 있다. 이중 하나는 아키텍쳐에 관련된 것이고 다른 하나는 클래스와

서브시스템(subsystem)의 상세 설계에 관련된 것이다.

Page : 20

먼저 아키텍쳐 관점에서 웍플로우를 살펴보면 제일 먼저 아키텍쳐 분석 액티비티를 통해

아키텍트는 아키텍쳐가 어떻게 조직되는가를 정의한다. 이 과정에서 아키텍트는 시스템을 위한

모델링 협약(convention), 주요 매커니즘, 기본적인 아키텍쳐상의 패턴을 식별한다. 예를 들어

아키텍트는 계층화(layering) 원칙, 서브시스템을 조직하는 원칙, 재사용 전략 등을 정의한다.

아키텍쳐 분석은 프로세스 계획을 위해서 반드시 필요하다.

다음으로 충분하게 유스 케이스 분석이 수행되면 결과로 생성된 클래스를 아키텍쳐 설계

액티비티에서 사용한다. 아키텍쳐 관점에서 중요한 클래스를 식별하고 설계 패키지나

서브시스템으로 그룹화하는 일도 수행한다. 그런 다음 서브시스템을 알맞은 계층으로

조직화한다. 병행성 기술(Describe Concurrency) 액티비티는 아키텍쳐를 프로세스 관점(Process

View)에서 발전시키는 작업을 의미하며 분산 기술(Describe Distribution) 액티비티는 아키텍쳐를

배포 관점(Deployment View)에서 발전시키는 작업으로 아키텍쳐 설계작업의 연장이라고 할 수

있다.

이번에는 서브시스템의 설계 관점에서 분석 & 설계 웍플로우를 관찰해 본다. 유스 케이스의

실현(realization)에 대해 기술한 유스 케이스의 분석 결과로부터 설계자는 클래스의 특징과 관계를

식별하고 클래스를 더 자세히 정의한다. 이 과정에서 설계자는 아키텍쳐의 설계를 이용한다. 또한

서브시스템 인터페이스를 정의한다. 서브시스템의 인터페이스는 서브시스템에 포함된 클래스의

설계를 참조하여 만들어진다. 그런 다음, 유스 케이스를 다시 완전하게 설계한다. 유스 케이스의

실현(realization)은 Sequence 다이어그램이나 Collaboration 다이어그램에서 클래스 또는

서브시스템간의 상호 연산(operation)을 통해 완전하게 명시된다.

시스템이 대규모의 데이터를 포함하고 있을 때에는 데이터베이스 설계자는 persistent 클래스를

데이터베이스의 테이블에 할당하는 등의 작업을 아울러 수행한다.

라) 도구 지원

앞서 언급한 모델을 표현하는 데 사용되는 언어는 UML 이며, 다양한 산출물과 연관된 모델링

지침도 UML 로 표현되어 있다. 따라서 모델을 작성하고 관리하는 데 가장 적합한 도구는 Rational

Rose 이다. Rose 는 다양한 프로그래밍언어로 라운드 트립 엔지니어링 기능(순공학 + 역공학)을

제공하여 설계와 코드가 완벽하게 동기화될 수 있게 한다.

또한 Rational Unified Process 는 UML 과 Rose 를 사용하여 올바르게 분석 & 설계할 수 있도록

유용한 정보를 제공한다. 실시간 시스템의 분석 & 설계에 사용하는 모델링 도구인 Rose RealTime

은 설계한 모델의 시뮬레이션 기능도 제공한다. 또한 Rational SoDA 를 이용하여 문서 또는

보고서의 작성을 자동화할 수 있다. 예를 들어 SoDA 를 이용하여 RequisitePro 의 요구사항

분석내역과 Rose 의 설계 모델로부터 정보를 추출하여 알맞은 양식의 보고서를 생성할 수 있다.

Page : 21

마) 요약

분석과 설계를 통해 요구사항과 구현사이의 갭을 메우게 된다. 분석 & 설계 웍플로우는 유스

케이스를 사용하여 일련의 객체를 인식하고, 인식된 객체들은 클래스, 팩키지,

서브시스템으로 다듬어 진다.

아키텍트(큰 그림을 담당), 설계자(세부사항을 담당), 데이터베이스 설계자(persistence 를

다루기 위한 지식을 필요로 하는 세부사항을 담당)가 분석 설계단계의 책임을 나누어 갖는다.

분석과 설계의 결과는 3 가지 아키텍쳐 관점으로 추상화된 설계 모델이다. 논리적 관점

(Logical View)은 시스템을 클래스, 서브시스템, 패키지, collaboration 과 같은 논리적 요소로

나눈 모습을 나타내며 프로세스 관점(Process View)은 이러한 논리적 요소의 시스템의

프로세스와 쓰레드로의 매핑을 보여준다. 마지막으로 배포 관점(Deployment View)은

분산환경에서 프로세스의 실행될 노드(컴퓨터)로의 매핑을 나타낸다.

별도의 분석 모델이 시스템의 개략적인 모습을 표현하는 데 유용하게 쓰일 수 있는 경우도

있다.

Page : 22

2.5 구현 웍플로우

가) 목적

구현 웍플로우는 다음과 같은 네가지 목표를 갖는다.

계층화된 서브시스템의 관점에서 코드의 체계를 정의

컴포넌트로 클래스와 객체를 구현

개발된 컴포넌트의 단위 테스트

개발된 컴포넌트를 하나의 실행 가능한 시스템으로 통합

구현 웍플로우의 영역은 개별적인 컴포넌트의 단위 테스트까지로 국한된다. 시스템 테스트와

통합 테스트는 테스트 웍플로우에서 이루어진다.

나) 작업자와 산출물

구현 웍플로우의 작업자와 산출물의 관계

구현 웍플로우에 포함된 주요 작업자는 다음과 같다.

구현 담당자(Implementer) : 컴포넌트와 연관된 산출물을 개발하고 단위 테스트를 수행

시스템 통합 담당자(System Integrator) : 빌드를 수행

기타 작업자는 다음과 같다.

아키텍트(Architect) : 구현 모델(계층화와 서브시스템)의 구조를 정의

코드 검토 담당자(Code Reviewer) : 코드의 품질 검사 및 프로젝트 규정의 준수 여부에 대한

검사

구현 웍플로우의 주요 산출물에는 다음과 같은 것이 있다.

구현된 서브시스템(Implementation Subsystem) : 컴포넌트와 다른 구현된 서브시스템의

콜렉션(collection); 이는 구현 모델을 작은 부분으로 나눔으로써 조직화하는 데 사용된다.

컴포넌트(Component) : 하나의 소프트웨어 코드(source, binary, executable), 또는 정보를 담고

Page : 23

있는 파일(start-up 파일, readme 파일); 여러 컴포넌트를 묶어서(aggregate) 하나의 컴포넌트를

만들 수도 있다. 여러 개의 실행파일로 구성된 어플리케이션이 한 예가 될 수 있다.

통합 빌드 계획(Integration Build Plan) : 컴포넌트와 서브시스템을 구현하는 순서와 시스템을

통합할 때 생성될 빌드를 정의한 문서

다) 웍플로우

앞의 그림은 구현 웍플로우를 나타낸다. 구현 모델의 구조에 기반하여 시스템 통합 담당자는

어떻게 시스템을 통합할 것인가를 정의한다. 서브시스템이나 컴포넌트를 담당하는 구현 담당자는

마찬가지로 서브시스템과 컴포넌트의 수준에서 이를 어떻게 통합할 것인가를 정의하고 코드와

관련 산출물을 개발하고 필요에 따라 코드를 수정하는 등의 실제 구현 작업을 수행한다. 개발이

완료되면 구현 담당자는 단위 테스트를 수행하고 서브시스템의 통합 작업을 수행한다. 이후

시스템 통합 담당자는 서브시스템을 통합하는 작업을 수행한다.

구현과 설계는 밀접한 관련이 있으며 따라서 설계 요소와 구현 요소 사이에는 분명한

연결고리가 존재한다. 클래스와 코드가 한 예가 될 수 있을 것이다. 많은 경우에 라운드 트립

엔지니어링(round trip engineering)은 설계와 구현을 밀접하게 관련지어 준다. 설계자와 구현

담당자의 역할을 둘 다 수행하는 사람은 설계 모델을 변경하고 이에 맞게 코드를 다시 생성할 수

있으며 또한 구현 내역을 변경하고 다시 이러한 변경을 반영할 수 있도록 설계 모델을 변경할 수

있다. 이러한 방법은 프로세스에서 설계와 구현간의 갭을 없애 설계를 구현으로 변환하는

과정에서의 오류 발생을 피할 수 있게 한다.

Page : 24

라) 도구 지원

전통적으로 구현은 편집기, 컴파일러, 링커, 디버거와 같은 고전적인 소프트웨어 개발 도구를

사용하여 수행한다. 오늘날에는 이러한 도구들이 통합되어 하나의 통합개발환경을 제공하는 것이

일반적이다. Rational 사도 UNIX 환경에서 Ada 와 C++ 개발환경을 제공하는 Rational Apex 라는

도구를 제공한다.

Rational Rose 는 라운드 트립 엔지니어링을 지원하여 설계와 구현 액티비티를 밀접하게

관련지어 준다. 또한 Purify 나 Quantify 같은 툴은 코드 상의 결함을 발견할 수 있게 한다. Rational

의 형상관리 툴인 ClearCase 은 개인별 작업공간(Workspace)을 제공하는 것 뿐만 아니라 동시에

컴포넌트와 서브시스템의 통합을 위한 작업공간도 제공한다. 변경 요구와 결함의 추적과 이로

인한 소스 코드의 변경을 관리하기 위해서는 Rational ClearQuest 를 사용할 수 있다.

마) 요약

개발주기 동안 점증적인 통합을 하는 접근법은 Rational Unified Process 의 주요 특징 중

하나이다.

라운드 트립 엔지니어링은 Rose 와 같은 도구에서 지원하는 기법으로써 설계와 구현을

밀접하게 연결시켜 주는 역할을 한다.

2.6 테스트 웍플로우

가) 목적

테스트의 목표는 제품의 품질에 대해 평가하고 보고하는 것이다. 테스트 웍플로우는 다음과

같은 액티비티를 포함한다.

객체와 컴포넌트간의 상호작용을 검증

소프트웨어를 구성하는 모든 컴포넌트가 올바르게 통합되었는가 검증

모든 요구사항이 올바르게 구현되었는가 검증

소프트웨어가 배포되기 전에 결함을 인식하여 해결

나) 작업자와 산출물

테스트 웍플로우의 주요 작업자는 다음과 같다.

테스트 설계자(Test Designer) : 테스트를 계획하고, 설계하고, 구현하고, 테스트의 결과를

평가하는 일을 담당한다. 테스트 설계자는 테스트 계획과 테스트 모델을 생성하고, 테스트

절차를 구현하며, 테스트의 효율성, 결과 등을 평가한다.

시스템 테스트 담당자(System Tester) : 시스템 테스트를 담당한다. 시스템 테스트 담당자는

테스트를 위한 준비와 테스트 수행, 테스트 수행의 평가, 오류 처리, 테스트 결과의 평가,

발견한 결함의 보고와 같은 일을 수행한다.

Page : 25

이외에 다음과 같은 작업자가 존재한다.

성능 테스트 담당자(Performance Tester) : 성능 테스트를 담당한다.

통합 테스트 담당자(Integration Tester) : 통합 테스트를 담당한다.

구현 담당자(Implementer) : 테스트를 위해 driver 나 stub 같은 특별한 코드가 필요할 때 이를

구현한다.

설계자(Designer) : 테스트를 위해 driver 나 stub 같은 특별한 코드가 필요할 때 이를 설계한다.

테스트 웍플로우의 작업자와 산출물의 관계

테스트 웍플로우의 주요 산출물에는 다음과 같은 것이 있다.

테스트 계획(Test Plan) : 테스트의 목적에 대한 정보를 수록. 테스트 계획에는 사용할 전략과

테스트를 구현하고 수행하는 데 필요한 자원에 대한 정보를 기술한다.

테스트 모델(Test Model) : 테스트 항목(Test Case)과 테스트 절차(Test Procedure), 테스트

스크립트(Test Script)로 구성된다.

워크로드 모델(Workload Model) : 워크로드 모델은 성능평가를 위해 사용된다. 워크로드

모델에는 시스템의 실제 특성과 최종 사용자가 사용할 기능, 실제 작업부하 등을

Page : 26

시뮬레이션하는 성능 테스트에서 사용할 변수와 변수의 값에 대한 정보가 정의되어 있다.

결함(Defects) : 실패한 테스트로부터 생성되고 하나의 변경요구로 등록된다.

이외에도 다음과 같은 산출물들이 존재한다.

테스트를 위한 패키지와 클래스

테스트를 위한 서브시스템(Subsystem)과 컴포넌트(Component)

다) 웍플로우

앞의 그림은 일반적인 테스트 웍플로우이다. 이는 다음과 같은 액티비티를 포함한다.

테스트 계획(Plan Test) : 테스트 설계자는 테스트 요구사항, 필요자원 그리고 테스트 전략

등에 대한 상세한 요구 사항을 식별하여 이를 테스트 계획으로 문서화한다.

테스트 설계(Design Test) : 테스트 설계자는 테스트 대상을 분석하여 테스트 모델과 성능

테스트를 위한 워크로드 모델을 개발한다.

테스트 구현(Implement Test) : 테스트 설계자는 테스트 모델에서 정의된 테스트 절차를

자동화 도구를 사용하여 테스트 스크립트로 레코딩하거나 수작업으로 프로그램화한다. 만약

테스트 수행을 위해 드라이버나 스텁(stub)과 특별한 코드가 필요한 경우 테스트 설계자는

설계자나 구현 담당자와의 공동 작업을 통해 이를 구현한다.

Page : 27

테스트 수행(Execute Test) : 테스트 담당자는 테스트 대상에 대하여 테스트를 수행한다.

테스트의 수행에는 테스트 절차(수동 수행시)나 테스트 스크립트(자동 수행시)를 이용한다.

테스트가 완료되면 테스트담당자는 결과를 검토한다. 검토 과정을 통하여 테스트가

적절하게 실행되었는지를 파악한 후 결과를 문서화하고 결함이 발견되면 이를 등록한다.

테스트 평가(Evaluate Test) : 테스트 설계자는 테스트 결과를 평가하여 정량화할 수 있는

측정값을 제공한다. 이를 통해 테스트 설계자는 테스트 대상의 품질과 테스트 프로세스의

효율성을 결정할 수 있다.

라) 도구 지원

테스트는 개발주기동안 반복적으로 여러 번 수행된다. 테스트의 효과를 극대화하기 위해서는

테스트 자동화를 위한 도구를 사용하는 것이 반드시 필요하다. 특히 테스트에 수천대의 기계가

필요하고 또한 이들 장비의 동기화가 필요한 부하 테스트의 경우에는 테스트 자동화를 위한

도구가 절대적으로 필요하다.

Rational 사는 다음과 같이 테스트 자동화를 위한 다양한 도구를 제공한다.

RequisitePro : 테스트 요구사항을 추적하고 관리한다.

Purify : 신뢰성 테스트 도구로 런타임 에러를 찾아 준다.

Quantify : 소프트웨어 실행시의 타이밍 정보를 측정하고 이를 통해 병목지점을 찾아 준다.

PureCoverage : 테스트 수행시의 코드 커버리지 정보를 제공한다. 커버리지 정보는 테스트의

완전성(Completeness)을 평가할 때 유용하게 사용된다.

TeamTest : 소프트웨어의 기능 테스트를 위해 필요한 도구들을 제공한다.

PerformanceStudio : 시스템의 부하 테스트를 위해 필요한 도구들을 제공한다.

ClearQuest : 결함을 추적, 관리하기위해 사용한다. 또한 ClearQuest 는 프로젝트 진척상황에

대한 다양한 보고서를 제공한다.

이외에도 Rational Unified Process 는 이러한 도구를 효과적으로 사용하는 방법에 대한 정보를

제공한다.

마) 요약

제품의 품질은 제품을 구성하는 모든 요소의 품질과 생산된 최종 제품의 품질을 말한다.

프로세스의 품질은 프로세스 자체의 구현과 프로세스, 표준, 지침에 대한 준수여부에 대한

측정으로 표현될 수 있다.

품질은 모든 사람의 책임이다.

테스트 웍플로우는 컴포넌트간의 상호작용, 통합, 기능, 성능의 관점에서 제품의 품질을

평가하는 데 주 목적이 있다.

Page : 28

2.7 형상 및 변경 관리 웍플로우

가) 목적

형상 및 변경 관리 웍플로우의 목적은 프로젝트 진행과정에서 변화하는 프로젝트 자산의

무결성을 추적 유지하는 것이다. 개발주기 동안에 많은 가치 있는 산출물들이 생성된다. 이러한

산출물을 생성하는 데에는 많은 노력이 투입되고 따라서 가치 있는 투자 대상으로 생각할 수 있다.

그렇기 때문에 이러한 산출물은 보호되어야 하며 쉽게 재사용될 수 있어야 한다. 또한 이러한

산출물은 반복적인 개발과정에서 계속해서 발전되고 계속해서 업그레이드된다. 산출물을

담당하는 작업자가 있지만 사람의 기억에 의존하여 이러한 소중한 자산을 관리하는 것은 위험한

일이다.

프로젝트 팀원은 산출물을 식별하고 접근할 수 있어야 한다. 이를 통해 알맞은 버전의 산출물을

선택할 수 있고, 산출물의 현재상태와 변경 사유를 설명한 변경이력을 볼 수 있으며, 현재 누가

산출물에 대한 책임을 지고 있는가를 파악할 수 있다. 동시에 프로젝트 팀은 제품의 발전과정을

추적하고, 다양한 곳으로부터 발생하는 변경요구를 수집하여 관리하고, 일관성 있게 산출물에

변경요구를 구현할 수 있어야 한다. 또한, 프로젝트 관리 웍플로우를 지원하기 위해 중요한

프로젝트 산출물에 대한 상태정보를 제공해야 하고 주요 산출물의 변경에 관련된 평가기준을

수집해야 한다.

나) 작업자와 산출물

형상 및 변경 관리 웍플로우의 주요 작업자는 다음과 같다.

프로젝트 관리자(Project Manager) : 전체 소프트웨어 개발 계획(SDP)의 한 요소인 형상 관리

계획에 대한 책임이 있다.

형상 관리자(Configuration Manager) : 개발과 통합을 위한 작업공간(Workspace)을 정의하고

할당하는 것을 포함한 형상관리 시스템 구축에 대한 책임을 진다(형상 관리 시스템을 구축할

때에는 개발하는 시스템의 구조를 적절히 반영해야 한다.). 또한 형상 관리자는 프로젝트

관리자를 위해 상태 및 평가 보고서를 작성한다..

다음과 같은 작업자도 형상 및 변경 관리 웍플로우에 관련되어 있다.

구현 담당자(Implementer) : 자신이 맡은 변경 사항을 구현하기 위해 필요한 산출물과

작업공간을 이용한다.

통합 담당자(Integrator) : 통합 작업공간에서 변경 사항을 수용하여 제품을 빌드한다.

임의의 작업자(any worker) : 변경 요구를 제출할 수 있다.

아키텍트 : 구현 관점(Implementation View)을 통해 개발하는 시스템의 구조에 대한 정보를

제공한다.

Page : 29

변경 제어 위원회(Change Control Board:CCB)는 프로젝트 관리자, 아키텍트, 형상 관리자, 고객

대표, 마켓팅 담당자 등과 같은 기술 및 관리적으로 관심을 갖는 다양한 인원으로 구성된

그룹이다. CCB 의 역할에는 변경의 영향 평가, 우선순위 결정, 변경 승인 등이 있다.

형상 및 변경 관리의 주요 산출물에는 다음과 같은 것이 있다.

형상관리 계획(Configuration Management Plan : CM Plan) : 형상관리 계획은 버전 관리,

작업공간 관리, 변경요구 관리, 빌드, 릴리즈와 같은 프로젝트의 형상관리 작업에 사용할

정책 및 실무를 기술한다.

변경 요구(Change Requests) : 변경 요구는 문서상의 결함, 요구사항의 변경, 소프트웨어의

버그 등 매우 다양한 형태를 갖는다. 모든 변경 요구에는 제출자와 원인에 대한 정보가

포함된다. 추후의 영향 분석(Impact Analysis)은 연관된 산출물, 비용, 스케쥴 등의 관점으로

변경의 영향을 첨부한다. 변경 요구는 작업이 진행됨에 따라 상태가 변경된다. 이력 정보(

특히 변경제어 위원회(CCB)의 결정사항)는 변경 요구에 첨부되어 관리된다.

또한 다음과 같은 산출물도 형상 및 변경 관리 웍플로우에 포함된다.

구현 모델(Implementation Model) : 형상관리자가 형상관리 환경을 구축하기 위해 필요한

개발하는 제품에 대한 정보를 제공한다.

평가기준 및 상태 보고서(Metrics and Status Reports) : 상태 평가 보고서는 CM 과 CRM 지원

환경으로부터 정보를 추출하여 작성한다.

다음 그림은 형상 및 변경 관리 웍플로우에서 작업자와 산출물의 관계를 보여준다.

다) 웍플로우

형상 및 변경 관리에는 두개의 서로 밀접한 관계를 갖는 웍플로우가 있다. 하나는 형상관리

측면의 웍플로우이고 다른 하나는 변경 요구 관점의 웍플로우이다. 형상 관리 측면에서의

웍플로우는 다음과 같다.

1. 프로젝트 관리자는 프로젝트에 사용될 구체적인 CM 실무를 정립하여 CM 계획을 작성한다.

Page : 30

2. 소프트웨어 아키텍처 문서(구현 관점 : Implementation View)의 정보에 기반하여 형상

관리자는 제품 구조를 확립하고, 개발자와 통합자에게 필요한 다양한 작업공간을 생성하여

할당한다.

3. 작업자는 자신의 작업 공간에 접근하여 산출물을 수정한다. 특히, 자신에게 할당된 변경

요구를 구현한다.

4. 통합자는 통합 작업공간에서 변경을 수용하여 제품을 빌드한다. 빌드한 제품은 테스트

대상이 된다.

5. 새로운 기준버전(baseline)이 반복의 끝에서 생성된다.

형상관리 측면에서 바라본 형상 및 변경 관리 웍플로우

변경 요구의 관점에서 본 웍플로우는 약간 달라진다.

1. 변경 요구 입력

2. 변경 요구가 산출물, 비용, 스케쥴에 미치는 영향을 분석한다.

3. 변경제어 위원회(CCB)는 영향 분석, 변경된 우선순위를 검토하여 변경요구를 승인한다.

4. 변경 요구를 구현을 위해 작업자에 할당한다.

Page : 31

5. 변경 사항을 새로운 빌드에 통합하여 테스트한다.

6. 변경 요구가 종료

라) 도구 지원

모든 변경을 관리하는 것은 대단히 어렵다. 변경 요구를 정확히 관리하는 것의 어려움은 시간이

지날수록, 팀의 크기가 커질수록, 제품의 크기(즉, 산출물의 수)가 커질수록, 팀이 지리적으로

분산되어 있을수록, 일정이 촉박할수록 기하급수적으로 커진다. 이처럼 변경요구 관리는 오류가

발생하기 쉽고, 많은 인적자원이 소모되는 작업이므로 도구의 지원을 통한 자동화로서 많은

이익을 얻을 수 있다. 래쇼날은 형상 및 변경 관리 웍플로우를 다음의 도구를 통해 지원한다.

ClearCase 는 형상 관리를 지원한다.

ClearQuest 는 변경 요구 관리와 프로젝트의 상태 평가를 지원한다.

마) 요약

형상 및 변경 관리 웍플로우의 목적은 변경요구를 처리하면서 발전(evolve)하는 과정에서

프로젝트 산출물의 무결성을 유지하는 것이다.

형상관리는 제품의 구조, 구성요소의 식별, 구성요소의 유효한 형상, 그리고 작업공간을

다룬다.

변경요구 관리는 일관성 있게 산출물을 변경하는 프로세스를 포함한다.

상태와 상태 평가에 도움이 되는 평가기준(metrics)은 형상과 변경 관리 정보로부터 추출할 수

있다.

ClearCase 와 ClearQuest 같은 도구는 형상 및 변경 관리 웍플로우의 단조로운 작업 대부분을

자동화한다.

2.8 환경 웍플로우

가) 목적

환경 웍플로우의 목표는 프로세스와 도구를 통해 개발조직을 지원하는 것이다. 환경

웍플로우에서의 지원 내역은 다음과 같다.

도구 선정과 획득

Toolsmithing : 도구를 조직에 맞게 커스터마이즈하고 필요에 따라 추가로 도구를 개발하는

것을 말한다.

프로세스 구성(Process Configuration)

프로세스 개선(Process Improvement)

교육(Training)

프로세스를 지원하기 위한 기술 서비스 : IT(Information Technology) 하부구조, 사용자 계정

Page : 32

관리, 백업…

나) 작업자와 산출물

환경 웍플로우의 작업자와 산출물의 관계

환경 웍플로우의 주 작업자는 프로세스 엔지니어(Process Engineer)이다. 프로세스 엔지니어는

소프트웨어 개발 프로세스에 대한 책임을 지는 작업자를 말한다. 프로세스 엔지니어는 프로젝트

시작 전에 개발 프로세스를 구성하고 프로젝트 기간동안 프로세스를 계속해서 개선한다.

환경 웍플로우의 주 산출물은 개발 케이스(development case)이며 이는 개별적인 프로젝트를

위해 알맞게 고쳐진 프로세스를 말한다.

환경 웍플로우에서 프로세스 엔지니어는 프로세스의 지침(guideline)을 만들기 위해 다음과 같은

작업자의 도움을 필요로 한다.

비즈니스 모델 분석가(Business Model Analyst) : 비즈니스 모델링 지침

시스템 분석가(System Analyst) : 유스 케이스 모델링 지침

사용자 인터페이스 설계자(User-Interface Designer) : 사용자 인터페이스 지침

아키텍트(Architect) : 설계 지침

Technical writer : 사용자 매뉴얼 양식 지침

또한 다음과 같은 작업자가 도구 환경(tool environment)을 설정하는 데 참여한다.

Toolsmith : 단조롭고 오류 발생의 소지가 높은 작업을 자동화하기 위해, 특별한 요구사항을

Page : 33

해결하기 위해, 또는 도구들간의 통합을 지원하기 위해 필요한 도구를 개발한다.

시스템 관리자(System Administrator) : 하드웨어와 소프트웨어 개발 환경을 유지하며 사용자

계정 관리, 백업과 같은 시스템 관리 업무를 수행한다.

환경 웍플로우의 주요 산출물은 소프트웨어 개발 환경(software development environment)이며

이는 하드웨어, 소프트웨어, 네트웍 자원, 소프트웨어 도구, 개발과 테스트 액티비티를 위한

소프트웨어 지원으로 구성되어 있다.

다) 웍플로우

환경 웍플로우는 일반적으로 다음과 같은 액티비티로 구성된다.

프로세스의 구성(Configuring the Process)

프로세스의 구현

도구의 선정과 획득

- 모델링을 위한 도구

- 요구분석을 위한 도구

- 코드 개발을 위한 도구(편집기, 컴파일러, 디버거)

- 형상관리와 변경요구 관리를 위한 도구

- 테스팅을 위한 도구

- 계획(planning)과 추적(tracking)을 위한 도구

- 문서화 준비를 위한 도구

Toolsmithing

개발 지원

교육(Training)

라) 요약

환경 웍플로우의 목적은 도구, 프로세스, 방법론(method)의 측면에서 개발조직에게 적절한

지원을 하는 것이다.

Rational Unified Process 에서 많은 액티비티와 단계들은 래쇼날사의 여러 개발 도구 사용을

통해 자동화된다. 따라서 소프트웨어 개발과정에서 오류가 발생하기 쉽고, 인적 자원을 많이

요구하는 단조로운 작업 대부분을 피할 수 있게 해 준다.

Page : 34

2.9 배포 웍플로우

가) 목적

배포 웍플로우의 목표는 제품을 최종사용자에게 전달하는 것이다. 배포 웍플로우는 다음과 같은

다양한 범위에 걸친 액티비티를 포함한다.

소프트웨어의 완성된 외부용 릴리즈를 생산 및 조립

소프트웨어의 포장

소프트웨어의 유통

소프트웨어의 설치

사용자와 또는 영업사원의 교육

사용자 지원

베타 테스트의 계획과 수행

기존의 소프트웨어 혹은 데이터의 마이그레이션

공식적인 인수(Formal Acceptance)

배포는 도메인과 비즈니스에 대단히 밀접하게 관련되어 있다. 따라서 알맞은 배포 웍플로우를

구성하기 위해서는 Rational Unified Process 를 커스터마이즈하는 것이 필요하다.

나) 작업자와 산출물

배포 웍플로우의 작업자와 산출물의 관계

배포 웍플로우에 관련된 작업자는 다음과 같다.

배포 관리자(Deployment Manager) : 배포를 계획하고 조직화한다.

구현 담당자(Implementer) : 릴리즈할 소프트웨어를 생성한다.

Technical writer : 사용자 매뉴얼, 설치 지침서 등을 작성한다.

교육 개발자(Course Developer) : 교육 자료를 작성한다.

배포 웍플로우의 주요 산출물은 다음과 같다.

배포 계획(Deployment Plan)

Page : 35

사용자 매뉴얼

교육 자료 : 슬라이드, 온라인 튜토리얼, 컴퓨터를 이용한 교육(CBT : Computer-Based

Training)을 위한 자료

다) 웍플로우

배포 웍플로우에서 일어나는 일반적인 액티비티에는 다음과 같은 것들이 있다.

소프트웨어의 생산 : 소프트웨어의 완제품에는 다음과 같은 산출물들이 포함되어 있어야

한다.

- 테스트 완료된 제품

- 설치 프로그램

- 사용자를 위한 문서

- Configuration Data

- 데이터 변환과 같은 마이그레이션 작업을 위한 별도 프로그램

소프트웨어의 포장

소프트웨어의 유통 : 상자에 포장해서 유통하는 것으로부터 인터넷을 통한 유통 등 다양한

형태를 취할 수 있다.

소프트웨어의 설치

마이그레이션(migration) : 마이그레이션은 다음과 같은 작업을 포함할 수 있다. 경우에

따라서는 마이그레이션을 위한 별도의 프로그램을 개발할 필요가 있다. 물론 이때에도 주

제품을 개발할 때와 같은 프로세스를 사용할 수 있다.

- 기존의 시스템을 신 시스템으로 대체

- 기존의 데이터를 새로운 형식으로 변환

사용자 지원(Providing Assistance to the Users) : 사용자 지원은 다음과 같이 다양한 방법으로

이루어질 수 있다.

- 공식적인 교육

- 컴퓨터를 이용한 교육(Computer-Based Training)

- 온라인 지원

- 전화를 통한 지원

- 인터넷을 통한 지원

- 부수적인 자료 : 팁, 어플리케이션 노트, 예제, 마법사…

라) 요약

배포 웍플로우는 최종 사용자와 마케팅, 유통, 영업을 담당하는 지원 조직에 전달될 모든

산출물을 다룬다.

배포 웍플로우는 개발된 제품과 해당 비즈니스의 유형에 크게 의존한다. 따라서 Rational

Unified Process 를 채택한 조직에서는 반드시 배포 웍플로우를 커스터마이즈해야 한다.

3. Rational 의 자동화 도구

Page : 36

Category 제품 기능 Language/DB

소프트웨어

개발

프로세스

Rational

Unified

Process (RUP)

온라인 소프트웨어 개발 프로세스

검증된 최고의 사례 지원

온라인 지식기반

온라인 멘터 기능

Rational 의 기타 개발도구와 통합

Web 을 통한 접근 지원

요구사항

관리

RequisitePro 요구사항 추적 자동화

요구사항의 변경이력 관리

요구사항의 공유저장소 제공

손쉬운 커스터마이징

E-mail 을 통한 discussion group 기능

MS Word 와 통합

다양한 데이터베이스 지원

Web 을 통한 접근 지원

지원 DB :

MS Access,

MS SQL

Server6.5/7.0,

Oracle7.3.x

비주얼

모델링

Rose 2000 UML 에 기반한 모델링

Booch’93, OMT-2 표기법 지원

다양한 코드 생성 기능

데이터베이스 모델링 지원

CORBA 2.2 지원

라운드 트립 엔지니어링 지원

- 모델과 코드간의 지속적인 일관성 보장

다중 사용자 지원

Rose 확장 인터페이스 지원

RoseScript 지원

MS VisualStudio 와 통합

Rational 의 기타 개발도구와 통합

RoseLink 파트너 제품 지원

Web 을 통한 접근 지원

C++,

Java,

VisualBasic,

Oracle8,

Ada

…

Rose RealTime UML 에 기반한 RealTime 시스템 모델링

모델로부터 실행 가능한 코드 생성

모델 시뮬레이션 기능

Rational 의 기타 개발도구와 통합

RoseLink 파트너 제품 지원

C++

Page : 37

Category 제품 기능 Language/DB

변경 및

형상관리

ClearCase 디렉토리와 그 하위 디렉토리의 버전 유지

분기를 통해 동시 개발 지원

버전의 비교와 병합의 자동화

작업공간 관리

Unix 와 윈도우 스타일의 makefile 을 지원

헤더파일 의존성을 포함한 소스파일

의존성을 자동 감지

자동으로 빌드 감사 후 BOM 생성

병렬/분산 빌드 지원

Raima DB 내장

ClearCase

Multisite

분산 병렬 개발을 위한 복제 VOB

자동적인 VOB 갱신

연속 개발 모델 지원

ClearCase 와의 완벽한 통합

ClearQuest 변경요구 관리

변경되는 소프트웨어의 이해

신속한 리소스 조정

간소화되고 자동화된 웍플로우 지원

생산성 향상

ClearCase 와 통합

간편한 최적화, 유지, 및 배치

MS-Access,

MS-SQL server,

SQLAnywhere,

Oracle

테스팅 Purify OCI(Object Code Insertion)기술 채택

소스코드 없이 런타임 에러 검사 가능

정교한 메모리 검사 기능

개발환경에 완벽하게 통합

C, C++

Quantify OCI(Object Code Insertion)기술 채택

병목지점에 대한 추적 기능

다양한 성능측정 정보 제공

개발환경에 완벽하게 통합

C, C++,

Visual Basic,

Java,

Fortran

PureCoverage OCI(Object Code Insertion)기술 채택

코드의 커버리지 분석 기능

다양한 커버리지 분석 정보 제공

개발환경에 완벽하게 통합

C, C++,

Visual Basic,

Java,

Fortran

Page : 38

Category 제품 기능 Language/DB

TeamTest 객체 테스팅(Object Testing) 기술 채택

포괄적인 테스트 자산 관리(TestManager)

다양한 테스트 수행

기능 테스트, 스트레스 테스트, 볼륨 테스트,

성능 테스트, 사용자 인터페이스 테스트, 회귀

테스트

다양한 개발환경 지원

웹 사이트 테스트

테스트 결과 분석 및 보고서 작성

결함 보고 및 추적 기능

통합 저장소 제공

팀 단위 테스트 환경 지원

Rational 의 기타 개발도구와 통합

Performance

Studio

DataSmart레코딩, ClientSmart레코딩,

LoadSmart 스케쥴링, ServerSmart 재생 기술 채택

포괄적인 테스트 자산 관리(TestManager)

정확하고 확장성 있는 성능 테스트

기능 테스트와 성능 테스트 동시 수행

다양한 네트워크 레코딩 방식 지원

웹 사이트 테스트

실시간 모니터링

다양한 테스트 결과 분석 결과 제공

통합 저장소 제공

팀 단위 테스트 환경 지원

Rational 의 기타 개발도구와 통합

지원 Protocol :

Oracle,

DB/2,

Sybase,

SQL Server,

HTTP,

HTTP/SSL,

Tuxedo/Jolt,

Socket,

SAP,

CORBA,

DCOM

기타 SoDA 다양한 기능의 템플릿 제공

Rational 의 개발도구와 통합

정보 출처와 문서를 동기화

점증적인 문서 생성 기능

수동입력정보 보전 기능

WISIWYG 방식으로 템플릿 생성 기능

MS Word 와의 밀접한 통합

4. 웍플로우와 도구 지원

Page : 39

4.1 웍플로우에서 자동화 도구의 용도

웍플로우 도구 용도

요구사항 RequisitePro Vision, Glossary, UseCase Specification, Supplementary

Specification등 요구사항 관련 정보의 관리

Rose 유스 케이스 모델 작성

분석 & 설계 RequisitePro 유스 케이스 관련 문서 및 요구사항 관리

Rose UML 을 이용한 소프트웨어의 비주얼 모델링

구현 Rose 소프트웨어 시스템 모델링, 라운드 트립 엔지니어링

Rose RealTime 실시간 시스템의 모델링, 라운드 트립 엔지니어링,

시뮬레이션

Purify 런타임 에러 교정

Quantify 단위 프로그램의 성능 개선

테스트 RequisitePro 테스트 요구사항 관리

Purify 런타임 에러 식별

Quantify 단위 프로그램의 성능 측정

PureCoverage 테스트의 커버리지 분석

TeamTest 시스템 기능 테스트

PerformanceStudio 시스템 성능 평가

ClearQuest 결함 등록 및 추적

프로젝트 관리 ClearQuest 프로젝트의 상태 평가

형상 & 변경 관리 ClearCase 다양한 프로젝트 산출물의 형상관리 및 작업공간 관리

ClearQuest 다양한 변경요구의 관리

공통 RUP 실용적인 소프트웨어 개발방법론

SoDA 자동 문서화 도구

Page : 40

4.2 웍플로우별 필수 작업자(주: 인원은 프로젝트 인원 30 명 기준)

웍플로우 필수 작업자(역할) 인원3 사용 도구

요구사항 시스템 분석가 10 RequisitePro, Rose

유스 케이스 명세 담당자 10 RequisitePro, Rose

아키텍트 10 RequisitePro, Rose

분석 & 설계 아키텍트 10 Rose

설계자 10 Rose

데이터베이스 설계자 10 Rose

구현 구현담당자 20 Rose, Purify, Quantify

시스템 통합 담당자 20 Purify, Quantify

테스트 테스트 설계자 2 RequisitePro, TestManager

통합 테스트 담당자 20 TeamTest, PureCoverage

시스템 테스트 담당자 10 TeamTest, PureCoverage

성능 테스트 담당자 2 PerformanceStudio

프로젝트 관리 프로젝트 관리자 1 ClearQuest

형상 & 변경 관리 전 작업자 30 ClearCase

전 작업자 30 ClearQuest

공통 전 작업자 30 RUP

문서화 관련 작업자 15 SoDA

4.3 자동화 도구의 사용 시점(주: 인원은 프로젝트 인원 30 명 기준)

툴 \ 웍플로우 요구사항 분석 & 설계 구현 테스트 권고수량4

RequisitePro ←───── ─────→ 10

Rose ←───── ────── ─────→ 16

Purify, Quantify ←───── ─────→ 20

PureCoverage ←───── ─────→ 10

TestManager5 ←───── ────── ────── ─────→ 10

TeamTest ←───── ────── ─────→ 10

PerformanceStudio ←───── ────── ─────→ 1

RUP ←───── ────── ────── ─────→ 30

3 한 사람은 하나 이상의 작업자가 될 수 있다.4 Node-locked 라이센스 기준5 TestManager 는 TeamTest 와 PerformanceStudio 에 포함되어 있음

Page : 41

ClearCase ←───── ────── ────── ─────→ 30

ClearQuest ←───── ────── ────── ─────→ 30

SoDA ←───── ────── ────── ─────→ 15* RequisitePro 는 시스템 분석가 인원 기준* Rose 는 구현 담당자 인원의 80%* Purify, Quantify 는 구현 담당자 인원 기준* PureCoverage, TeamTest(TestManager)는 시스템 테스트 담당자 인원 기준

Page : 42