rup development...

One Step Ahead

RUP Development SolutionRUP Development Solution객체지향개발방법론, CBD방법론의 이해

김상일

[email protected]

2

- One Step Ahead -

RUP의 기본개념 Copyright ⓒ NEXTREE SOFT CO., LTD., 2007, All Rights Reserved.

ContentsContents

1.1. RUPRUP의의 기본개념기본개념

2.2. 비즈니스비즈니스 모델링모델링 공정공정(Business Modeling Discipline)(Business Modeling Discipline)

3.3. 요구요구 명세명세 공정공정(Requirements Discipline)(Requirements Discipline)

4.4. 분석분석 & & 설계설계 공정공정(Analysis & Design Discipline)(Analysis & Design Discipline)

5.5. 구현구현 공정공정(Implementation)(Implementation)

6.6. 데이터데이터 모델링모델링(Data Modeling)(Data Modeling)

7.7. 테스트테스트(Test)(Test)

8.8. 배포배포(Deployment)(Deployment)

1. Rational Unified Process1. Rational Unified Process의의기본개념기본개념

4

- One Step Ahead -


RUP RUP 프레임워크프레임워크Global View

종합적인관점에서유스케이스패키지만을다룬다.

All Packages패키지만으로시스템을설명

Architecturally Significant Model Elements

중요한모델요소만별도로모아서정리

Global View, Overview전체적인개요를이해하기쉽게큰영역의패키지만을다룬다.

5

- One Step Ahead -


RUP RUP 구조구조RUP 프로세스구조도

가로축 -프로세스의동적인구조시간에따른작업단계(Phases)

세로축 -프로세스의정적인구조공정(Disciplines)들을작업순서대로나타낸다.

하단부의반복(Iterations)단계별로일련의공정들이반복된다는것을보여준다.

6

- One Step Ahead -


RUP RUP 빌더빌더 (1)(1)RUP 빌더(Builder)는특정프로젝트참여자가표준으로참조할 RUP의세부항목들을조정하는도구

프로젝트에필요한플러그인(Plug-Ins)과프로세스만남겨두고프로젝트와관련이없는것은모두제거하는식으로RUP의활동들을선별하여적용할수있게프로젝트단위혹은개인별로설정한다.

프로젝트규모지정

7

- One Step Ahead -


RUP RUP 빌더빌더 (2)(2)프로세스지정

8

- One Step Ahead -


RUP RUP 빌더빌더 (3)(3)역할별뷰프로세스지정

9

- One Step Ahead -


RUP RUP 빌더빌더 (4)(4)게시작업

10

- One Step Ahead -


프로젝트의프로젝트의 흐름흐름 (1)(1)프로젝트의일반적인흐름

Rational Unified Process를이용하여시스템을구축하는것새로운요구사항들을소프트웨어공학적인처리를통하여목표시스템을구축하는것이다.

새로운요구

변경요구

변경구축된시스템

소프트웨어공학처리소프트웨어공학처리

11

- One Step Ahead -


프로젝트의프로젝트의 흐름흐름 (2)(2)RUP의진행과정 (1)

초기전체적인계획을수립하고, 시스템구축의방향을설정한다.

비즈니스모델링

비즈니스모델링을추진하면서시스템구축의토대를구축한다.

요구명세과정

사용자와이해관계자의요구를정의한다.

분석, 설계과정요구사항들의상세분석을수행하고기술적형식으로요구들을변형시킨다.

구현과정

시스템을구축한다.

테스트과정

구현된시스템을테스트하고결함을보정한후전체적인평가한다.

다음반복계획을수립하고요구명세분석설계및구현과테스트과정을시스템이완성될때까지순환과정을반복한다.

배포각과정을진행할때에는형상및변경관리, 환경관리를수반하며최종적으로는구축된시스템을배포한다.

12

- One Step Ahead -


프로젝트의프로젝트의 흐름흐름 (3)(3)RUP의진행과정 (2)

13

- One Step Ahead -


산출물산출물전체작업과정

수평적으로는단계(Phase)로나누고

수직적으로는공정(Discipline)으로나누어체계적으로관리하는것은필수적이다.

프로젝트초기에각작업구간마다산출해야할산출물과산출물의개발수준을지정하고작업이진행되면세분된각작업구간마다일정한작업성과가산출물에누적되고최종적으로는완성된시스템이산출물로구현된다.

모든산출물은이해당사자들의요구에서출발하며각공정에서나오는산출물의핵심은공정별모델이된다.

전체프로젝트계획이나반복계획그리고형상관리문서등각종아키텍처들이부수적으로수반된다.

14

- One Step Ahead -


모델모델 (1)(1)산출물의흐름 (1)

이해당사자들의요구사항은용어집이나비전에반영되고이것들을토대로유스케이스모델과보충명세서를작성한다.

유스케이스모델을토대로분석설계모델과유스케이스구현인구현모델을만들고이들을검증하기위한테스트모델을만든다.

산출물의흐름외에프로젝트계획이나위험관리, 변경관리등의산출물들은모든공정에배경으로서관계한다.

이해당자사요구사항이해당자사요구사항

용어집비전

용어집비전

유스케이스모델보충명세서

유스케이스모델보충명세서

설계모델구현모델테스트모델

설계모델구현모델테스트모델

15

- One Step Ahead -


모델모델 (2)(2)산출물의흐름 (2)

프로젝트계획에따라각공정들이순차적으로진행되면각작업구간마다산출물들을생성하게되는데대표적인산출물이모델이다.

모델목표시스템의개발수준별로시스템을명확하게설명하기위한틀이며다이어그램과부속문서들로구성된다.

비즈니스모델링공정

비즈니스유스케이스모델을먼저만들고이것을토대로비즈니스유스케이스를실현하는비즈니스분석모델을만든다.

비즈니스모델은요구명세공정의유스케이스모델이나분석설계공정의설계모델로진화한다.

요구명세공정

요구명세공정의유스케이스모델은시스템의기본으로서설계모델로실현되거나구현모델로구현되거나테스트모델로검증된다.

16

- One Step Ahead -


모델모델 (3)(3)공정과모델의연관

유스케이스모델에서설계모델로실현되기전의중간단계로서분석모델을제작하면좀더쉽게설계모델을도출할수있게된다.

이경우에도구현모델과테스트모델은모두유스케이스모델을기본으로한다.

BusinessModelingBusinessModeling RequirementsRequirements Analysis

& DesingAnalysis& Desing ImplementationImplementation TestTest

BusinessUseCase Model

BusinessObject Model

UseCaseModel

DesignModel

ImplementationModel

Test Model

공정들Disciplines

모델들Models

Realized By

Realized By Verified ByImplemented By

Automated By

분석모델

17

- One Step Ahead -


RUP RUP 반복반복 (1)(1)단계별반복

반복의실체

반복(Iterations)은전체시스템과정에서동일한범위를대상으로재차개발과정을실행하는것이다.

하나의반복은잘게나누어진미니프로젝트(Mini Project)이고개발방법으로는폭포수개발방식을따르는미니폭포수(Mini Waterfall)이다.

다른반복들과동떨어진것이아니라다른반복들과연관된하나의요소로서상호연관을갖는다.

18

- One Step Ahead -


RUP RUP 반복반복 (2)(2)실무적관점에서의반복

하나의반복이끝나면워크숍을가져서다음반복의범위를정하고반복계획을수립한다.

반복기간의작업흐름은추가된업무에대하여비즈니스모델링을수행하고상세한유스케이스명세를작성하며앞의반복작업과연계하여분석설계를추가한다음일부에대하여코드구현을하고테스트를한다.

이와같이 RUP는기본적으로미니프로젝트의반복을통한점진적진화를지향한다.

하나의반복은미니프로젝트로서계획과요구명세분석, 설계, 구현, 테스트등의일련의과정이모두포함된다.

앞뒤의각반복에는점증적으로진화된차이가존재하므로결국은점증적인개발을수행하면서앞의반복결과인산출물들은다음반복의입력으로서투입되는순환관계를갖는다.

전체적인반복의주요흐름은중요한부분들을먼저수행하고다음반복에서앞의작업을보정하면서범위를넓혀개발하는것이므로종합적으로보면나선형개발과유사하다.

그러나중간에피드백이한과정으로서명확히실행되고반복계획수립을하는중간거점으로서이정표개념이있다는점에서나선형개발과는분명한차이가있다.

19

- One Step Ahead -


RUP RUP 반복반복 (3)(3)나선형개발방법의작업흐름

Products(end)

Inception(Idea)

Elaboration(Architecture)

Construction(Beta Releases)

Transition(Products)

start

20

- One Step Ahead -


RUP RUP 반복반복 (4)(4)반복개발과위험의관계

나선형진화주기의반복은자연스럽게시뮬레이션학습을경험하게하여양질의산출물을가져온다.

위험에대한조기발견과사전예방효과도있고재사용의수준을높이며새로발견된상황에유연하게대처할수있다.

반복이진화될때마다역점사항이반복별로진화되므로품질관리도유리하다.

폭포수개발방법과반복개발방법의위험비교 (1)폭포수개발방법

분석과설계를처음에완벽하게끝내고다음단계로진행하는고전적인개발방법

특정영역에대한반복개발은전혀고려되지않는다.

21

- One Step Ahead -


RUP RUP 반복반복 (5)(5)폭포수개발방법과반복개발방법의위험비교 (2)

반복1 반복2 반복3 반복4 반복5 반복6

위험의 심각성

InceptionWaterfall

Elaboration

ConstructionIterative,Incremental

WaterfallIntegration andTest Period

Time

22

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (1)(1)RUP의 4단계

RUP는전체일정을 4단계로나누며단계별로반복작업을진행하는공정들에역점을둔다.

즉, 작업을반복해나가면서시스템을누적하여진화시키고일정수준에도달하면다음단계로진행한다.이때각단계들을구분하는일정수준은형식화되어산출물들을포함한요소들로평가하는데이것을이정표(Milestone)라고하며작업단계를넘어다음단계로진화할수있는합격기준선이된다.

이정표(Milestone) 설정폭포수방식개발

각단계별로각기다른작업을마무리하면서자연스럽게매듭지어진다.

RUP 반복개발각반복이공정세트를모두순환하므로단계별구분이명확하지않게되는단점을보완한다.각단계별목표기준을두어이것이달성되어야다음단계로진행할수있고, 달성되지않으면되돌아가다시개발해야한다는것을명확하게하기위하여단계별개발목표로이정표를둔다.RUP에서는단계계획즉, 이정표계획말고는프로젝트의전체세부계획을작성하지않기때문에이정표가명확히설정되지않으면개발수준을평가할수있는중간목표달성기준이없어지게되므로프로젝트진행이곤란해진다.

23

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (2)(2)단계별이정표와반복

이정표(Milestone)는각단계별로 1개씩모두 4개가존재한다.

이정표(Milestone)는각단계에서다음단계로의진행을승인하는최종심사기준이며앞단계에서충족시켜야할필수요건이다.

Lifecycle

Objectives

Milestone

Lifecycle

Architecture

Milestone

Initial

Operational

Capability

Milestone

Product

Release

Milestone

time

24

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (3)(3)도입단계(Inception) (1)

시작단계라고도하며, 프로젝트개발을위한예비단계로프로젝트평가성격을가지며기간도 1주에서 2주정도로다른단계에비해짧은편이다.

그러나프로젝트수주와관련하여수집하거나작성된자료도동원되므로업무기간구분은명확하지않은것도있으나도입단계에서모든것을정리하여구체화시켜야한다.

25

- One Step Ahead -



비즈니스모델링과요구명세그리고분석/설계공정이포함된다.

업무파악과범위결정혹은프로토타입(prototype)을개발하는데주안을둔다.

위험식별을포함하여비즈니스모델혹은비즈니스객체모델, 아키텍처모델, 유스케이스모델, 분석모델, 설계모델등의초기버전이산출된다.

따라서대략도메인모델의기본적인조사혹은얕은수준의분석을한다.

동일한프로젝트의수행경험이있거나자료가있다면무척간단해진다.

정확한범위설정과계획수립을위하여프로토타입이개발되는경우반복개발이적용될수있다.

이때최초반복에서일단핵심을중심으로얕은수준으로완성하고다음반복에서세밀하게재검토하여프로토타입의코딩작업까지완성한다.

요구사항에대한용어집이나비전문서, 프로토타입모델개발, 파악된업무범위에대한개략적인수준의유스케이스등이개발된다.

정련단계를위한반복계획과위험목록, 기본적인요구사항보조명세서등이산출된다.

코딩은개념증명을위한프로토타입개발에서이루어진다.

26

- One Step Ahead -



도입단계에서는전체업무범위에서비즈니스모델링의 60% 정도가작성된다.업무범위전체에해당되는모든액터와유스케이스식별및명세가얕은수준에서작성된다.

약 10%~30% 정도의유스케이스명세는상세하게작성하여소프트웨어개발계획과반복계획수립의구체적인자료로그리고이러한계획의개념증명근거로삼는다.분석설계의 10%가수행되고약간의코드가프로토타입으로개발된다.

프로젝트수행을위한컴퓨팅환경설정이나작업서버설치, 문서형식과관리체계확정등이도입단계에서수행된다.

LCO(Lifecycle Objectives Milestone), 생명주기목표이정표도입단계의활동, 산출물들에대한수행목표, 프로젝트범위, 프로젝트개발계획등이 LCO에포함된다.비용관리, 범위관리, 위험식별, 개발계획의타당성등과같은전반적인사안을다룬다.프로젝트전반에대한청사진을다루기때문에이해관계자들의동의를구하는것이중요하다.이정표로서목표수준을점검하기위한여러기준이제시되는데이것은단계별합격여부판단의기준이된다.도입단계에서의모든산출물은초안형태이거나추정치에의한자료이므로그한계를명확히인식해야하고프로젝트를진행하면서정교하게구체화되도록지속적으로정련하여야한다.

27

- One Step Ahead -



도입단계이정표의점검지침

기본산출물 이정표지침

비전문서(Vision) 프로젝트의 주요 요구사항, 핵심 개발 대상, 주요 제약 조건 포함 여부

비즈니스평가(Business Case) 비즈니스 평가의 정의와 증명 여부

위험목록(Risk List) 프로젝트 위험 식별 여부

소프트웨어개발계획

(Software Development Plan)소프트웨어 개발 계획의 지속 기간과 목표 규명 여부

투입 자원 및 개발 환경 등의 자원 추정과 비즈니스 평가의 일치 여부

반복계획(Iteration Plan) 정련 단계 첫 반복 계획 수립 여부 및 타당성 검토

개발시나리오(Development Process) RUP에 대한 조정과 확장에 대한 문서화 여부와 타당성 검토

도구들(Development Infrastructure) 프로젝트 지원 도구들과 반복 작업에 필요한 도구들의 설치 여부

용어집(Glossary) 중요 항목 정의 여부

유스케이스모델

Use-Case Model(Actors, Use Cases)중요 액터와 유스케이스 식별 여부 및 핵심 유스케이스 상세 명세 작성 여부

환경관리 프로젝트 저장소와 변경 요구에 필요한 환경관리 설정 설치 여부

옵션산출물 이정표지침

유스케이스지침서 유스케이스모델링지침서작성여부

도메인모델

Domain Model(Business Analysis Model)시스템의핵심개념및용어확장문서화및타당성여부

프로젝트형식 프로젝트상세문서형식이산출물문서들을개발하는데사용되는지여부

프로토타입(Prototypes) 전략적중요사항에대한개념증명필요성및타당성여부

28

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (7)(7)정련단계 (Elaboration) (1)

최초반복중요한부분을중심으로요구사항분석과유스케이스명세를작성하며클래스식별등의분석과설계를한다.

두번째반복우선순위에따른요구사항분석과설계구현및테스트를한다.

이단계에서는반복을최소한 2회이상실행하며중요한부분은코딩을먼저시작하지만전체적으로는분석과설계에반복의중점이두어진다.

29

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (8)(8)정련단계(Elaboration) (2)

이단계는도입단계의모든작업을진화시키는단계로서분석/설계공정에역점을둔다.비즈니스모델링과요구사항기술공정의비중이약간줄어들고대신분석/설계공정과구현공정의비중이늘어난다.비즈니스모델링공정과요구사항공정에대한완벽한마무리를유도하며재조정된위험식별이나상세한버전의산출물들을생성한다.프로세스구조도에서는 2회반복을제시하였지만반복횟수의제한은기본적으로없으므로프로젝트상황에따른다.

프로젝트상황에따라다르지만일반적으로RUP의각반복의기간은 4주정도가적합하다고본다.프로젝트규모가크고개발자의수가상대적으로적은편이라면반복횟수를늘리는것이합리적이다.

정련단계에서는유스케이스의 50%~90%가상세하게작성되고, 분석/설계는 60%, 코드는 30% 정도가완성되어야한다.

참여개발자들의대부분이RUP 초보라면교육을위한짧은반복으로 1~2주정도로선행하고고난도의잔여업무처리를후행으로하여반복하는것도좋다.

만약설계즉시코드를생성하는동시모델링과역공학설계가적용된다면이들을감안하여정련단계에서의코드생성비율을더높여야한다.각반복의결과는다음반복의시발점으로그리고다음반복계획수립의입력자료가되므로전체개발계획은이정표를중심으로고정되며반복계획은오직다음반복하나만수립하므로비교적유동적이다.

그러나추정치로만수립된전체개발계획은반복을거듭할수록구체적인정확도를가지게된다.

30

- One Step Ahead -



LCA(Lifecycle Architecture Milestone), 생명주기아키텍처이정표정련단계에서는상당작업이수행된상태이므로 LCA에서는제반작업이안정적인지의여부와정련단계의실행성과가구축단계로의진입이가능하도록달성되었는지여부를확인한다.

구체적으로는정련단계에서의비전과요구명세, 아키텍처가안정적인지의여부, 주요위험요소들의해결여부, 자원및계획의정확성여부, 비용타당성여부등이점검된다.

정련단계이정표의점검지침

LCA에서는안정성에역점을두어점검하되그동안의자료를바탕으로정확한비용및인력자원의예측을토대로정교한프로젝트반복계획이수립되고진행되고있는지를확인한다.

31

- One Step Ahead -



정련단계이정표의점검지침 (1)기본산출물 이정표지침

프로토타입(Prototypes) 중요 기능과 시나리오 검증을 위한 실행 아키텍처 프로토타입 생성 여부

위험목록(Risk List) 위험 목록의 정련 여부 및 비기능적인 요구 명세들과의 연계 검토 여부

개발시나리오(Development Process) 이전 프로젝트 경험의 반영 여부와 프로세스, 도구, 자동화의 적정성 여부

도구(Development Infrastructure) 정련 단계 작업을 지원하는데 사용되는 도구 설치 여부

소프트웨어아키텍처문서

(Software Architecture Document)중요한 유스케이스(뷰), 핵심 기능의 규명, 그리고 논리적인 뷰와 필요할 경우 분산 배치 뷰와 프로세스 뷰의 정의 여부 및 기준선화 여부

설계모델(Design Model)설계 모델과 산출물들 정련 및 기준선화 여부, 중요한 시나리오의 유스케이스 실현 정의, 요구되는 행위 할당 여부, 컴포넌트 규명 여부, 프로젝트 관리 결정 요소의 타당성여부

데이터모델(Data Model) 데이터 모델 정련 및 기준선화, 주요 데이터 모델 요소 식별 및 적정성 여부

구현모델(Implementation Model) 구현 모델 초기 구조 생성, 주요 컴포넌트 규명, 프로토타입 실행 여부

비전(Vision) 중요 사항들에 대한 비전 정련과 기준선화 여부

반복계획(Iteration Plan) 구축단계를위한반복계획의완성, 검토여부

소프트웨어개발계획

(Software Development Plan)소프트웨어 개발 계획의 구축과 전수 단계 포함 여부

지침서 지침서(설계 지침서나 프로그래밍 지침서) 적용 여부


Use-Case Model(Actors, Use Cases)모든유스케이스와액터식별여부, 유스케이스상세명세작성여부

보충명세서(Supplementary Specifications) 비기능적요구명세들을포착하는보조부가명세의문서화및검토여부

테스트작업세트(Test Suite) 테스트작업세트(suite)와정련단계의실행버전의테스트구현및실행여부

테스트아키텍처(Test Automation Architecture) 테스트자동화의핵심소프트웨어요소에대한기준선화구성여부

32

- One Step Ahead -



정련단계이정표의점검지침 (2)

옵션산출물 이정표지침

비즈니스평가

(Business Case)프로젝트 변경 요소 식별 및 반영 여부

분석모델

(Analysis Model)생략 가능하며 설계 모델의 초기 버전 대신에 포함되어 유지 관리 가능함

훈련자재

(User Support Material)사용자 매뉴얼과 다른 훈련 자재들 준비 및 내용 수준 점검

프로젝트형식 문서 산출물들을 개발하는데 사용되는 문서 형식 설정 여부

33

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (12)(12)구축단계(Construction) (1)

구축단계에서는요구사항정리가안정되고시스템구축도일부되어있는상태에서코딩과시스템구현에중점을두어반복을실행한다.

반복횟수는 3회이상으로N회까지로필요한만큼설정하되최초반복은중요한부분부터시작한다.

두번째반복에서는최초반복에서누락되고상대적으로덜중요한부분을구현한다.

코드구현은반복의모든범위에서진행되며테스트에도상당한시간과노력을기울인다.

34

- One Step Ahead -



구현공정에역점을두면서새롭게추가되거나변경된영역에대한비즈니스모델링이나요구사항기술공정에대한작업이계속진행된다.

이단계에서는구현과배치에역점을두어누적진화해온각종모델들, 아키텍처관련산출물등을포함하여실행가능한소프트웨어를완성한다.

이단계에서는대략 10% 내외의나머지유스케이스를마저상세하게작성하고분석설계의 20%, 코드의 60% 정도, 테스트및배치의 70% 정도가구축단계에서작성된다.

반복횟수가많아지면서발견된문제점들이지속적으로반영되고조정된다.

이단계에서삽입되는요구명세와분석설계는앞에서해결되지않은미결사항이나각단위업무가종합되는합계마감업무, 지역업무, 기타잔여부분이처리된다.

구현된프로그램들이누적되고서브시스템들을누적통합하게되므로더욱복잡해지면서테스트공정수행작업이많아지므로통합관점에서품질관련요구사항을최대한만족시키려노력하는단계이다.

35

- One Step Ahead -



IOC(Initial Operational Capability Milestone), 초기운영능력이정표초기운영능력이정표는구축단계의목표로서모든기능들이개발되고개발자테스트인알파테스트가마무리되며사용자매뉴얼과현재버전에대한설명등과함께제품을양도할준비가되었는지를점검한다.

구축단계에서는시스템구축이완료되는단계이므로요구사항이충족되고각기능이잘상호작용하는지의여부가중요한점검사항이다.

자원투입비용이지속적으로점검되어야하고사용자의운영매뉴얼등도작성되어야한다.

IOC 지침사용자에게제품인도가가능한지여부를기준으로삼는다.

기존의요구된기능이모두정상적으로작동되는지를테스트하고검증하였는지, 사용자매뉴얼이나훈련자재등이필요한수준으로만들어졌는지를종합적으로확인한다.

구축단계에서새로추가된요구사항에대한관련모델요소에의반영여부를점검한다.

36

- One Step Ahead -



구축단계이정표의점검지침


시스템(System) 베타 테스트용으로 준비된 애플리케이션 시스템 자체 점검

배포계획(Deployment Plan) 배포 계획 수립 실행 여부

구현모델(Implementation Model) 정련 단계의 산출물에서 도출된 구현 모델 점검

테스트작업세트(Test Suite) 실행 버전에 안정성을 검증하기 위한 테스트 점검

훈련자재(User Support Material) 유스케이스에 기초한 사용자 매뉴얼과 다른 훈련 교육 자재 점검

반복계획(Iteration Plan) 전이 단계를 위한 반복 계획 수립과 검토 여부

설계모델(Design Model) 새로 규명된 새로운 설계 요소들의 설계 모델 반영 여부

개발시나리오(Development Process) 개발 시나리오 정련 여부, 프로세스와 자동화 지원 개발 환경 여부

도구들(Development Infrastructure) 구축 작업에 필요한 도구 설치 여부

프로젝트형식 표준문서형식사용여부

데이터모델(Data Model) 지속 구현에 필요한 요소 반영 여부

옵션산출물 이정표 지침

보충명세서

(Supplementary Specifications)새로운요구명세들의반영여부


Use-Case Model(Actors, Use Cases)새로운유스케이스들(액터들, 유스케이스들)의반영여부

37

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (16)(16)전이단계(Transition) (1)

전이단계에서는산출물들을사용자측에최초에설치한후에발생되는여러문제들을해결하는과정이반복의대상이된다.규모에따라버그수정이나환경설정변경수준일수도있지만새로운기능을추가할때에는분석설계혹은구축단계부터시작해야하는경우도있다.일반적으로는개발된소프트웨어에대하여최종마무리를하여발주자에게인도하는단계이다.

38

- One Step Ahead -



새롭게발견된사항에대한보수작업때문에혹은인수단계에서만처리할수있는작업때문에극히제한적이긴하지만비즈니스모델링과요구사항명세, 분석/설계가이루어지며 10%의코드구현및 20%내외의배치공정관련작업이이단계에서이루어진다.변경관리와프로젝트관리의약 10% 정도작업이전이단계에서이루어진다.사용자요구사항을다시현장에서테스트하거나결함을식별하고시스템인도후운영을위한산출물의정리등이포함되고사용자훈련과교육관련자재의작성도포함된다.

PR(Product Release Milestone), 제품버전이정표제품버전이정표에는전이단계의목표를정하며사용자들에대한교육과훈련기술지원등의내용이포함된다.PR은프로젝트의모든활동을공식적으로종료시킬수있는기준이된다.

즉, 제품버전이정표는성공종료의판단기준이며그렇기때문에프로젝트생명주기가종료되면서간혹다른프로젝트의도입단계와동시에진행되기도한다.그러나전이단계는아직제작중인상태이며제품버전직전버전으로운영을점검하는유지보수기간이다.

PR에서는사용자의만족에가장중요한역점을두지만비용이수용가능한지도고려하여야한다.

39

- One Step Ahead -



전이단계이정표의점검지침


제품빌드(The Product Build) 요구 명세와의 일치 여부 및 활용 가능 여부

버전주석 완료 여부

설치산출물 완료 여부

훈련자재 제품의 사용과 유지보수에서 고객의 자립 보장 여부

테스트작업세트(Test Suite) 안정성검증용테스트작업세트의현장제공가능여부

사용자지원자재(User Support Material) 제품의 사용과 유지보수에서 고객의 자립 보장 여부

옵션산출물 이정표 지침

압축포장패키징(Product Packaging) 산출물포장이제품소매에도움이되는지여부

40

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (19)(19)단계별프로젝트관리 (1)

정답은존재하지않으며프로젝트상황에따라계획은조정된다.

프로젝트 A의단계별작업비중 –단위 10%도입 – 2주 1반복, 정련 – 4주 4반복, 구축 – 4주 4반복, 전이 – 3주 2반복

전이단계의 2반복새로운요구사항이발견되어설치시의문제해결과정과분리하여해결하기위한것

도입단계에서프로젝트성공증명을위하여프로토타입을개발하였으므로코드구현과테스트가추가되어있고정련에서 4반복을두어반복을짧고자주갖는것이특징이다.

구분 도입 정련 구축 전이

비즈니스모델링 60% 30% 10% - 100%

요구명세 10% 70% 10% 10%

분석설계 10% 60% 20% 10%

구현 10% 20% 60% 10%

테스트 10% 20% 60% 10%

배치

형상/변경관리

프로젝트관리

환경관리

반복횟수

-

10%

20%

20%

10%

10%

20%

20%

30%

40%

70%

50%

50%

30%

40%

20%

20%

10%

20%

10%

41

- One Step Ahead -


RUPRUP의의 각각 단계와단계와 이정표이정표 (20)(20)단계별프로젝트관리 (2)

프로젝트 B의단계별작업비중 –단위 10%도입 – 2주 1반복, 정련 – 4주 2반복, 구축 – 4주 3반복, 전이 – 2주 2반복

지원공정은고정적으로할당하였다.

프로토타입을수행하지않고정련에서 2반복만을두어유연성이떨어지지만익숙한업무환경에서적용해볼만하다.

구분 도입 정련 구축 전이

비즈니스모델링 60% 30% 10% - 100%

요구명세 30% 50% 20% -

분석설계 10% 60% 20% -

구현 - 30% 60% 10%

테스트 - 20% 70% 10%

배치

형상/변경관리

프로젝트관리

환경관리

반복횟수

-

10%

20%

20%

10%

10%

20%

20%

30%

20%

70%

50%

50%

30%

30%

20%

20%

10%

20%

20%

42

- One Step Ahead -


RUP 4+1 RUP 4+1 아키텍처아키텍처 뷰뷰 (1)(1)아키텍처

Software Architecture in Practice [1]“소프트웨어아키텍처는소프트웨어요소와이들요소의외부속성그리고이들사이의관계를구성하는시스템의구조이다”

The software architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them

RUP“소프트웨어아키텍처는더작은컴포넌트들과인터페이스들이성공적으로구성된컴포넌트들과인터페이스를통하여상호작용을하는시스템조직과구조의컴포넌트들이다”

아키텍처(Architecture)는간단하게는시스템의조직과구조를설명하기위한시스템부가물이며, 소프트웨어아키텍처란특정관점으로본시스템구조도이다.

구조도는구성요소, 구성요소간의상호작용과기능등을포함하는포괄적인개념이다.

기술이나프로세스, 비용이나기능혹은제약조건등의시스템과관련된제반문제가모두포함될수있다.

43

- One Step Ahead -


RUP 4+1 RUP 4+1 아키텍처아키텍처 뷰뷰 (2)(2)아키텍처뷰

아키텍처뷰(Architecture View)는아키텍처의관점이다.

시스템의논리적인구성이나기능혹은병행성을다루거나설치위치등의특정관점에서시스템을해석한다.

아키텍처는시스템의일부이며프로젝트에서다루어야할일부분이다.

다이어그램은모델요소를그래픽으로표기한것으로특정아키텍처의부분이아니지만특정관점을앞에붙인다면아키텍처뷰의다이어그램이고아키텍처뷰의모델이될수있다.

그러므로아키텍처모델, 다이어그램은아키텍처뷰, 유스케이스모델, 유스케이스다이어그램과같은특정관점의그것과구분하여이해하여야한다.

시스템을아키텍처뷰라는관점에서해부하고설계하는것은좀더세밀하고안정적인시스템을구축하는기반이된다.

44

- One Step Ahead -


RUP 4+1 RUP 4+1 아키텍처아키텍처 뷰뷰 (3)(3)4+1 아키텍처뷰 (1)

RUP와UML에서중심이되는소프트웨어아키텍처를 4+1뷰라고정의한다.

Philippe Kruchten, “The 4+1 View Model of Architecture”, 1995.4 : 4개의구조, 1 : 1개의유스케이스

4개의분리된구조로구성되는아키텍처개념을제시

이들 4개구조가서로충돌되지않는지, 시스템의요구사항을충족시키는지를증명하기위해체크방법으로유스케이스를사용할것을제안

Kruchten은 1995년에발표한논문에서논리적인뷰(logical view), 개발뷰(development view), 프로세스뷰(process view), 물리적인뷰(physical view) 등 4개의뷰와시나리오(scenarios)라는용어를사용했다.

Kruchten은 2000년에출간된 The Rational Unified Process An Introduction(2nd Edition)에서는개발뷰(development view) 대신에구현뷰(implementation view)를사용하고, 물리적인뷰(physical view) 대신에배포뷰(deployment view)를사용하였고, 시나리오(scenarios) 대신에유스케이스뷰(use case view)를사용하였다.

유스케이스뷰가다른모든뷰에영향을미치며RUP의첫단계이고시작점이며시스템외부에서액터가시스템을보는관점에서시스템이갖추어야할모든기능들을집약한것으로사용자요구사항이모든뷰의토대, 다른뷰의근거, 다른뷰들을검증하는기준이된다.

45

- One Step Ahead -



대규모프로젝트나특정프로젝트의경우프로젝트에필요한특정관점에서시스템을분석하여그관점을하나의아키텍처뷰로정리할필요가있다.

병행성이없는경우에는프로세스뷰가없을수도있고 5개의뷰이외에도필요에따라기밀뷰(Secret View)나비용뷰(Cost View) 같은것을임의대로추가하여운용할수도있다.

논리뷰(Logical View)논리뷰

(Logical View)구현뷰

(Implementation View)구현뷰

(Implementation View)

프로세스뷰(Process View)프로세스뷰

(Process View)

최종사용자기능성

시스템 통합자성능확장성결과

프로그래머소프트웨어 관리

시스템 엔지니어시스템 토폴로지배치설치커뮤티케이션

class diagramsequence diagramcollaboration diagram

class diagramstatechart diagramactivity diagram

component diagram

deployment diagram

분석가/테스터행위

배치뷰(Deployment View)

배치뷰(Deployment View)

유스케이스뷰(Use Case View)

Use-case diagram

유스케이스뷰(Use Case View)

Use-case diagram

46

- One Step Ahead -



47

- One Step Ahead -



공정(Disciplines)과뷰(View)의생성관계

유스케이스뷰(Use Case View)유스케이스뷰는외부액터가인식하는시스템의기능을설명한다.시스템이구축해야할내용은모두유스케이스단위로쪼개져서유스케이스명세로설명되고정리되며작게나누어진다.유스케이스뷰는사용자의요구명세들을모두유스케이스로정리함으로써큰시스템을작은유스케이스단위로범위를좁혀접근함으로써개발을진행한다.비즈니스유스케이스모델

비즈니스업무를시스템에서재현하는것이다.시스템중심이아니라업무자체혹은고객, 비즈니스파트너관점에서모델링한다.

유스케이스모델목표시스템에대한사용자의요구사항들을유스케이스로정리한것이다.시스템사용자관점

공정 생성뷰 작업내용

요구명세 Use Case View 사용자요구사항을정리한다.

Logical View 각유스케이스들을실현하기위하여분석하고가능한방법을모색하여구현방법을설계한다.

Process View 유스케이스중에서병행혹은병렬성과관련된것들을상세하게분석/설계한다.

Deployment View 컴포넌트나파일들의하드웨어배치를지정한다.

분석/설계

구현 Implementation View 런타임파일을생성하고배치를지정한다.

48

- One Step Ahead -



논리뷰(Logical View)논리뷰는시스템의기능이어떻게구현되는지를내부관점에서설명한다.

Rose 브라우저의논리뷰에는분석모델, 설계모델, 비즈니스분석모델이존재한다.Sequence Diagram, Class Diagram, Collaboration Diagram

비즈니스분석모델

비즈니스유스케이스를실현하는비즈니스작업자와시스템과의상호작용이설명된다.

분석모델

분석클래스들

설계모델

패키지, 서브시스템, 클래스

프로세스뷰(Process View)프로세스와프로세서로시스템의분할을설명하며시스템의비기능적속성을다룬다.

class diagram, statechart diagram

프로세스뷰는비교적일반적인분석설계수준보다쓰레드, 프로세스등의병행성(concurrency)이나병렬성(parallelism)과같은런타임시스템환경과밀접한것이나물리계층에가까운계층의시스템구현을다루거나구체적으로내용을취급하므로 Rose 브라우저에서논리적뷰의설계모델하부에별도로분리하여위치한다.

49

- One Step Ahead -



구현뷰(Implementation View)실현단계의컴포넌트를정의하고그룹화한다.

구현뷰에서는컴포넌트다이어그램을사용하여소스코드의구성에역점을둔다.

컴포넌트완성을목표로한다.

구현모델에서는시스템의정적인구조와관련한컴포넌트와파일들의구성, 개발되는프로그램과서브시스템, 데이터베이스의위치와패키징, 컴포넌트의디렉터리배치등의작업이실제로나타나는모습을기준으로설명한다.

배치뷰(Deployment View)물리뷰(physical view)라고도하며컴포넌트들이각노드혹은하드웨어플랫폼에어떻게배치되는지, 각디바이스에어떻게연관되는지를배치다이어그램(deployment diagram) 사용하여설명한다.

최적하드웨어배치를통한성능향상을목표로한다.

프로세스뷰에서프로그램로직을위한병렬성과병행성을다루지만분산시스템에서하드웨어를고려하는배치뷰는또다른하부관점으로다루어야한다.

단일서버를통한배치와는달리분산시스템의경우에는배치방법에따른성능의차이가현격하므로트래픽테스트를바탕으로한대안비교가반드시선행되어야한다.

50

- One Step Ahead -


RUPRUP의의 99개개 공정공정RUP에서공정(Disciplines)은워크플로우를기준으로작업자와각세부활동을논리적인관련성에따라그룹화한것을의미한다.

유스케이스에서의실현관계

비즈니스모델링은기본적으로모든프로젝트에서요구사항분석을하기전에수행되는것이지만필수과정이아닌선택사항이므로실무에서비즈니스모델링을제외하는경우가많다.

51

- One Step Ahead -


참고문헌참고문헌[ 1 ] Bass, Software Architecture in Practice, 2nd Edition, Addison Wesley, 2003.

[ 2 ] Kruchten, The 4+1 View Model of Architecture, IEEE, 1995.

rup development...

Documents