멍청한 개발자의 일대기

RUP, The Rational Unified Process(옮기는 중) 본문

Study

RUP, The Rational Unified Process(옮기는 중)

멍청한 개발자 2020. 10. 20. 18:08

<!doctype html>

Object-oriented analysis and design

 

업무 인수 인계를 받기 이전에, OOAD에 대한 높은 이해를 하는 것이 좋다고 판단하여 Allen이 추천해준 Rational Unified Process Made Easy 라는 책을 바탕으로 이 문서를 작성하기로 했다. 정독보다는 이 책에서 추천한 brief overview 방식으로 읽은 후 예제를 풀어나가는 식으로 정리할 예정이다.

RUP, The Rational Unified Process

What is the RUP

 

스크린샷 2020-10-07 오후 5.12.57

 

The RUP is a software development approach that is iterative, architecture-centric, and use-case-driven.

The RUP is a well-defined and well-structured software engineering process.

The RUP is also a process product that provides you with a customizable process framework

 

RUP는 책에서 서술된데로 크게 위의 세가지 특징&차이점을 가진다고 볼 수있다.

그중 첫번째, '반복적이고 Architecture 중심적이며 Use-Case 중심적인 개발 접근 방식이다.' 너무 당연하거 아닌가? 라는 생각이 들지만 다음 Chapter에서 RUP가 이를 위해 얼마나 효율적이고 체계적인 방법을 제시하는 지를 보고나면 납득할 수 있을 것이다.

위에 나온 것 처럼 architecture-centric, use-case-driven도 빠질수 없지만 개인적으로 아마 여기서 제일 강조하게 되는건 역시 iterative 가 아닐까 싶다. 그렇게 느낀 이유는 Clean Architecture 에서도 강조하지만 아무래도 life-cycle 에 직접적인 연관이 있어서 그런거같다.

life-cycle, 한 '주기' 라고 말할 수도 있으며 이 주기를 기점으로 release 된다고 볼 수 있다. 이후 work flow&phases 에 대해서 설명은 되지만 일단 여기서는 생략하도록 하겟다.

 

두번째는 'well-defined 그리고 well-structured 인 소프트웨어 개발 프로세스다.' 아무래도 너무 포장하는 감이 없는듯한 문장이지만 이후 guide-line 에서 왜그런지 잘 설명해준다. 이에 대해 부가적인 설명으로는

누가 어떤 일을 하고, 어떻게 해야 하고, 언제 해야 하는지를 명확하게 규정한다. 또한 RUP는 project 의 life-cycle에 대해 잘 정의된 구조를 제공하며, 필수적인 지표와 의사결정 지점을 명확히 표현한다.

라고 서술되어 있는데, 아미 위에 말한바와 같이 다음 Chapter 에서 확인 할 수 있을 것이다.

 

세번째인, 'RUP는 소프트웨어 엔지니어링을 위한 customizable process framework를 제공하는 process product이기도 하다.' 이 부분에서 조금 생각이 필요했던거 같다. 특히 'product' 이라는 단어가 '이해가 안됐다?' 라고 말 할 수 있다. 아무래도 낯선 개념이기도 해서 개인적으로 조금더 찾아보았다.

RUP 제품은 process customization 및 authoring(제작)을 지원하며, 이를 통해 다양한 프로세스, 즉 프로세스 구성(Process Configuration)을 assembled 할 수 있다.

...

RUP 제품에는 분석가, 개발자, 테스터, 프로젝트 관리자, 구성 관리자, 데이터 분석가 및 기타 팀원에게 소프트웨어 개발 방법을 Guide하는 몇 가지 out-of-the-box Process Configurations 및 Process VIew 들이 포함되어 있다.

즉 RUP를 product 라고 말한 이유는 각 case-by-case 에 대해 즉각적으로 대응 할 수 있는 일종의 customizable form 이 존재하고 다양한 상황을 support 한다는 점을 들어 product 라고 말 할 수 있는 거같다.

  • 구체적으로 개발방법론 과 process product(?) 가 어떤 관계인지 제대로 이해하지 못했다. 이후 시간이 남으면 조사하기로 하였다.

 

다음 문단은 바로 이러한 특징들을 유지하기 위한 기본적인 규칙들에 대해서 서술한다. wiki 에서도 따로 RUP를 검색해보았는데 거기서 서술된 내용과는 어느정도의 차이는 있지만 일맥상통하는 이야기들이라 문제가 없다고 판단하였다.

Rational Unified Process 의 핵심에는 성공적인 반복 개발을 지원하고 필수적인 "Spirit of the RUP"를 나타내는 몇 가지 기본 원칙이 있다.

이러한 원칙은 수많은 성공적인 프로젝트에서 도출되었고 몇 가지 간단한 지침으로 세분화되었다.

The Spirit of the RUP Essential Principles

아무래도 영문이기도 하고 설명 또한 생각보다 길거나 의미가 애매모한 부분이 있어 추가로 검색해 보고나서 이해 가능한 범위내에서 재가공하여 작성했다.

  • Attack major risks early and continuously...or they will attack you.

큰 리스크들을 초기부터 지속적으로 관리해야 한다. 이를 계속 방치할 경우 이는 Time 의 문제가 아니라 Cost 의 문제가 된다.

  • Ensure that you deliver value to your customer.

고객이 이해하기 쉽게 요구사항을 전달하는 것도 중요하지만, 설계 및 구현 테스트 단계 등을 통해 정확한 요구사항을 작성해야 한다.

  • Stay focused on executable software.

문서, 설계도, 기획서 모두 좋지만 제일 좋은 지표는 executable software 다.

  • Accommodate change early in the project.

초기 요구사항에 대해서 설계 및 구현을 정확하게 파악할 수 없다. 이는 이후 충분히 변화 할 수 있다는 것을 뜻하며 Good-Enough System을 개발하기 위해서는 변화를 허용하고 적응해야 한다는 것을 의미한다.

  • Baseline an executable architecture early on.

초기부터 architecture 를 도입는 것이 좋다. 이는 개발의 유지보수 측면도 있겠지만 RUP에서 강조하는 점은 communication이다. 변화에 대해 부연설명 없이 빠르게 communication 할 수 있다는 점은 매우 큰 이점이다.

  • Build your system with components.

이 부분은 Clean Arhictecture 에서도 강조했던 부분이다. Components 화 할 수록 System 은 변화에 대해서 유기적으로 반응할 수 있다. 또한 이는 바로 위에서 말한 communication 과 같이 동일한 이점을 같는다.

  • Work together as one team.

책에서는 team sport 라는 표현을 사용하였는데, 자신이 담당하는 Role을 부여하며 이에 따라 product 에 대해 책임감을 느낄 수 있으며 이는 좋은 product 를 만듬에 있어 좋은 시너지 효과를 가져온다.

  • Make quality a way of life, not an afterthought.

test 를 일이 벌어지기 직전 또는 특정 상황이 아닌 주기적으로 모든 team member 가 계속해서 관리해야 high quality를 보장 받을 수 있다. 즉, quality check 는 task가 아닌 way of life 처럼 계속해서 해야만 한다는 것이다.

 

위와 같이 구성되어 있으며 위 principles 를 기반으로 process 가 작동되게 된다. 위 principles 을 보면서 Clean Architecture 와 동일한 목적성을 가지고 있다는 것을 알게 되었다.

변화에 대해서 빠르게 대응 할 수 있는 것을 특징으로 가지고 있다는 점이다.

Software 및 Product 개발에 있어서 변경은 불가피하다고 볼 수 있다. 위에 principles 을 작성하면서 느낀점은 Clean Architecture가 초기에 설계도를 어떻게 작성해야 나중이 편해지는가에 대해서 말한다면, 이 책은 이미 만들어진 설계 또는 제품에 대해서 얼마만큼 변화에 빠르게 대응할 수 있는가에 대해서 말하는거 같다.

 

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

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

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

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

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

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

     

A Well-Defined Software Engineering Process

스크린샷 2020-10-07 오후 5.18.32

Dynamic structure - The horizontal dimension represents the dynamic structure or time dimension of the process. It shows how the process, expressed in terms of cycles, phases, iterations, and milestones, unfolds over the lifecycle of a project

Static structure - The vertical dimension represents the static structure of the process. It describes how process elements—activities, disciplines, artifacts, and roles—are logically grouped into core process disciplines (or workflows).

RUP의 Overall Architecture는 위에 이미지와 같고 Two Dimentions 으로 구성되어있다. Dynamic aspect(horizontal)는 cycles, phases, interations 및 milestones를 나타내고, Static Aspect(vertical)은 activities, disciplines, artifacts 및 role을 나타낸다.

 

Dynamic Structure

스크린샷 2020-10-08 오후 3.49.28

사실상 RUP 자체가 Developer 만을 위한 개발 방법론이 아니기에 보다 product 개발에 있어 모든 부분을 전제로 깔고 RUP을 바라 봐야 한다.

Dynamic aspect 는 Time 과 제일 관련이 깊을 수 있다고 볼 수 있는데, 즉 Dynamic life-cycle을 나타낸고 이는 시간의 흐름에 따라 phase 로 나누고 단계별 milestone으로 표시된다. 이는 Static aspect 에서 나오게 될 role 에 따라 같은 milestone 에서 작업하는 내용이나 requirements 가 다르며, 이에 맡은 role 에 따라 tasks 를 수행해야 한다.

위의 이미지와 같이 Phase 가 구성되며 아래는 그에 따른 Objective들이다

  • Inception Phase - LOM
  • Build the business case
  • Understand the scope of the project
  • Get stakeholder buy-in to move ahead

어떤 시스템을 구축할 것인지에 대한 요구사항requerments에 대해 높은 이해를 해야하며. 많은 Business Risk를 완화하고, 시스템 구축을 위한 Bussiness Case를 생산하며, 프로젝트 진행 여부에 대한 모든 이해관계자stakeholder를 인수인계buy-in를 받는다.

 

  • Elaboration Phase - LAM
  • Mitigate major technical risks
  • Create a baselined architecture
  • Understand what it takes to build the system

기술적으로 어려울 수 있거나 문제가 될 수 있는 부분을 확인하고 정의해야한다.

Design, Implement, Test, baseline an executable Architecture, including sub-systems, their Interfaces, Key Components, and Architectural Mechanisms, such as how to deal with IPC or persistency. Address major technical risks, such as Resource contention Risks, Performance Risks, and data-security risks, by Implementing and validating actual code등등..

 

  • Construction Phase - IOC
  • Build the first operational version of the product

먼저 사전에 정의한 executable architecture에서 실행 가능한 First Verstion을 작성해야하며 이후 여러 개의 내부 및 Alpha-Release를 통해서 software를 사용 가능한 수준까지 끌어올려야 하며 user-needs 를 충족하는지에 대한 검증을 해야한다.

위 사항에 대한 검증이 완료되었다면 Installation 및 Support Documents와 training material를 포함하여 완전히 작동하는 Beta-Version을 Deploy함으로써 이 Phase 는 마무리 된다.

 

이 life-cycle의 초점은 개발 및 test 가능한 System 을 구축하고 그 위에서 동작 가능한 software 를 작성하는데 초점을 둔다. 따라서 여기서 structural 한 부분은 마무리되어야 한다.

 

  • Transition Phase - PR
  • Build the final version the product and deliver it to the customer

소프트웨어가 사용자의 요구를 충분히 충족하는지 확인해야한다.

이 과정에는 제품 product을 test하고 User Feedback에 따라 변경 가능한 조정을 하는 것이 포함된다.

life-cycle의 이 시점에서 User Feedback은 주로 product, configuration, Installation 및 사용 적합성과 같은 문제를 미세 조정하는데 초점을 맞추게 되며 만약 시스템적 문제, 즉 모든 주요 구조적 문제structural issues는 훨씬 더 일찍 해결되었어야 한다.

 

Objective 들을 보면 알 수 있지만 말그대로 특정 역할에 상관없이 product 에 대한 phase로 볼 수 있는데 phase 종결 여부에 따라또는 필요에 의해서 기간과 life-cycle 등이 바뀔 수 있으며, 즉 Time에 따라 종속적으로 변하기 때문에 때문에 Dynamic-aspect 라고 서술되어 있다.

Static Structure

스크린샷 2020-10-07 오후 5.34.27

• Roles(Workers) - who

• Activities - how

• Artifacts - what

• Workflows - when

Role 이라는 용어는 개인이나 그룹(또는 팀)의 행위behavior와 책임responsibility을 정의한다.

행위behavior는 Worker가 수행하는 Activities로 표현되며 Worker는 이에 상관관계를 가질 수 있는 일련의 Activities와 들을 부여받는다. Activities간에 상관관계를 갖는다는 말은 특정 Activities이 한 사람에 의해서 수행될 때 성취도가 높아질 수 있다는 것을 의미하며 일반적으로 Worker가 생성하고, 변경하고 통제하는 Artifact로 표현될 수 있다.

즉, 이해를 돕자면 상관관계를 가지고 있지 않는 업무를 받을 경우 업무에 대한 이해도와 자신의 Role에 대해 애매모해질 수 있는데 이 상관관계를 만듦으로써 Worker 자신의 boundery를 정의하고 또 수행 할 수 있으며 이는 보다 높은 책임감을 가지며 그에 따라 높은 성취도를 가질 수 있다는 것이다.

Roles(Workers)

작업자(worker)는 개인이나 그룹의 행위와 책임을 의미한다. 작업자는 개인이 착용할 수 있는 "모자hat"와 같은 개념으로 생각할 수 있다. 개인이 상황에 따라 여러 다른 모자를 쓸 수 있는 것처럼 개인(또는 그룹)은 경우에 따라 여러 다른 작업자가 될 수 있다. 또한 작업자는 하나 이상의 역할을 수행하는 것 외에도 특정 산출물의 소유자(owner)가 된다.

작업자의 예로는 다음과 같은 것이 있다.

  • 시스템 분석가(System Analyst) : 시스템 분석가의 역할을 하는 사람은 시스템의 범위를 정의하고 시스템의 기능의 초안을 작성한다. 또한 이를 통해 요구사항을 추출하고 유스 케이스를 모델링하는 작업을 주도적으로 수행하며 때로는 조정자의 역할을 한다.
  • 설계자(Designer) : 설계자는 클래스의 책임(responsibilities), 연산(operations), 속성(attributes)과 클래스간의 관계(relationships)를 정의하고 구현 환경에서 어떻게 적용될 것인가를 결정한다.
  • 테스트 설계자(Test Designer) : 테스트 설계자는 테스트의 계획, 설계, 구현 및 평가를 담당한다.

위의 "모자"를 여러개 쓸 수 있다고 표현한 것 처럼 Bart나 Allen이 위 3가지 역할을 전부 수행할 수 있음을 뜻한다. 그래서 책에서는 Roles 라는 단어로 Worker를 대체하는데 그 이유는 Worker라는 표현을 사용하면 말그대로 사람이 많아진 것 처럼 보이기 때문이다.

Activities

특정 작업자의 액티비티(activity)는 작업자의 역할에 따라 수행해야 하는 단위 업무를 말한다. 각각의 액티비티는 명확한 목적을 갖는다. 예를 들어 모델이나 클래스 또는 계획과 같은 특정 산출물을 생성하거나 수정하는 것이 일반적으로 액티비티의 목적이 될 수 있다. 모든 액티비티는 알맞은 작업자에게 배정된다.

액티비티는 일반적으로 몇시간에서 몇일정도가 소요되고, 보통 하나의 작업자에 의해 수행되며, 하나 혹은 적은 수의 산출물에 영향을 미친다.

 

  • 반복 계획(Plan an iteration) : 프로젝트 관리자라는 작업자에 의해 수행
  • 유스 케이스와 액터를 추출(Find use-cases and actors) :시스템 분석가라는 작업자에 의해 수행
  • 설계 검토(Review the design) : 설계 검토 담당자라는 작업자에 의해 수행
  • 성능 테스트 수행(Execute a performance test) : 성능 테스트 담당자라는 작업자에 의해 수행

 

또한 Activities 는 내부적으로 Steps 로 나눌 수 있다.

• Thinking steps : where the person playing the role understands the nature of the task, gathers and examines the input artifacts, and formulates an outcome

• Performing steps : where the role creates or updates some artifacts

• Reviewing steps : where the role inspects the results against some criteria

Artifacts

산출물(artifact)은 프로세스에 의해 생성되고 수정되고 사용되는 정보의 단위이다. 산출물은 프로젝트에서 최종 제품을 개발하는 과정에서 생성되고 사용되는 형태를 갖는 산물을 말한다. 산출물은 작업자가 특정 액티비티를 수행할 때 입력으로 사용될 수 있으며 또한 액티비티 수행의 결과로 생성될 수 있다. 객체지향 설계 용어로 말하면, 액티비티는 특정 객체(작업자)에 대한 연산이라고 할 수 있고 산출물은 이러한 액티비티의 파라미터라고 할 수 있다.

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

  • 유스 케이스 모델, 디자인 모델과 같은 모델
  • 모델의 구성요소, 예를 들면 클래스, 유스 케이스, 서브시스템(subsystem)
  • 비즈니스 케이스, 소프트웨어 아키텍쳐 문서와 같은 문서
  • 소스 코드
  • 실행 파일

Workflows

Roles, Activities, Artifacts의 단순한 나열만으로는 프로세스를 구성할 수 없다. 프로세스를 이루기 위해서는 가치있는 결과를 생성할 수 있게 하는 Activities의 순서와 작업자간의 상호작용을 기술할 수 있어야 한다. *웍플로우(workflow)*는 의미있는 결과를 생성하는 액티비티의 순서(sequence)를 말한다. UML에서 웍플로우는 Sequence다이어그램, Collaboration 다이어그램, Activities 다이어그램으로 표현된다.

스크린샷 2020-10-08 오후 5.50.33

 

Core workflows

스크린샷 2020-10-08 오후 5.51.28

앞의 그림은 Rational Unified Process의 구조를 나타낸다. 가로축은 시간의 흐름을 의미하고 세로축은 특정 시간대에서 수행해야 할 액티비티를 의미한다.

도표에서 가로축을 통해 소프트웨어 개발주기가 여러 번의 반복으로 이루어져 있는 것을 확인할 수 있고, 세로축에 있는 9개의 Workflow가 반복이 진행됨에 따라 얼마만큼의 비중으로 수행되어야 하는가를 확인할 수 있다.

그림에서와 같이 Rational Unified Process에는 9개의 핵심이 되는 Workflow가 존재하는데 이러한 웍플로우는 Roles와 Activites를 논리적인 관련성에 따라 분류한 것을 의미한다.

 

9개의 핵심 Workflow는 다시 6개의 엔지니어링을 위한 Workflow와 3개의 지원을 위한 Workflow로 나눌 수 있다.

그중 엔지니어링을 위한 Workflow에는 다음과 같은 것이 있다.

  1. 비즈니스 모델링 웍플로우Business Modeling workflow
  2. 요구사항 웍플로우Requirements workflow
  3. 분석 & 설계 웍플로우Analysis and design workflow
  4. 구현 웍플로우Implementation workflow
  5. 테스트 웍플로우Test workflow
  6. 배포 웍플로우Deployment workflow

그리고 3개의 지원을 위한 Workflow는 다음과 같다.

  1. 프로젝트 관리 웍플로우Project management workflow
  2. 형상 및 변경 관리 웍플로우Configuration and change management workflow
  3. 환경 웍플로우Environment workflow

 

6개의 엔지니어링을 위한 Workflow의 명칭은 전통적인 Waterfall Process의 순차적인 단계를 연상시키지만 Iterative Process에서 이러한 Workflow는 개발주기동안 여러 차례 반복된다는 점에서 차이가 존재한다.

스크린샷 2020-10-13 오후 12.30.17

3개의 지원 Workflow는 말 그대로 개발 과정 중 6개의 엔지니어링을 위한 Workflow를 지원하는 역할을 한다.

프로젝트 관리 Workflow는 개발 프로젝트를 계혹하고 관리하는 Activites를 관장하고, 환경 웍플로우는 개발 환경을 정의하고 관리하는 Activites를 관장한다. 형상 및 변경 관리 웍플로우는 다양한 개발 과정의 산출물을 형상관리하는 Activites와 다양한 변경요청을 관리하는 Activites를 관장한다.

실제 프로젝트를 위한 웍플로우는 이러한 9개의 핵심 웍플로우를 이용하여 구성되고, 프로젝트를 완성하기 위해 구성한 웍플로우를 여러 차례 반복하게 된다.

아래 그림과 같이 프로젝트 개발 중 여러 번 반복이 수행될 수 있지만 각각의 반복마다 주안점은 조금씩 달라진다. 초기의 반복에서는 분석에 중점을 두며, 다음 번 반복에서는 점차 분석&설계, 구현쪽에 중점을 두게 된다. 그리고 말기의 반복에서는 테스트와 배포에 중점을 두게 된다.

스크린샷 2020-10-13 오후 12.31.36

이 이후에는 각 Workflows 및 역할에 대해 어떠한 목적과 산출물이 나오는지 그리고 어떤 툴을 사용해서 관리하는 것이 좋고 팀을 어떻게 빌드하는 것이 좋은지에 대한 RUP의 사용 예시들과 결과들이 나온다.

 

Your Mission as a Developer

스크린샷 2020-10-14 오후 5.05.28

생각보다 때어낼껀 때면서 정리하게 되어 이어서 작성하게 되었다. 이 내용은 Chapter.4에 Developer's Guide to the RUP을 정리한 내용이다.

Overview of the Developer’s Tasks

Developer 가 수행해야할 Task 는 크게 아래와 같이 4개로 나눌 수 있으며 사실 이 Guide의 전체적인 내용이 아래 4가지를 어떻게 수행할 것인가에 대한 설명에 가깝다.

• Understand the requirements and design constraints

• Design, implement, and test use cases and components

• Design, implement, and test any necessary databases

• Frequently integrate your application with the work of other developers

 

Understand the requirements and design constraints

Developer로서, requirements을 이해하는 것이 필수적이며, 즉 Sytem&Software 가 수행해야 하는 tasks 에 대한 높은 수준의 이해understand하고 project 의 requirements 에 대해서 solution이 어떻게 부합하는지 더 많은 context를 이해관계자에게 제공하는 것이다.

 

특히 여기서 강조하는 것은 requirements에 불일치 가능성이다. 즉 사용자가 전달한 requirements 자체가 잘 작성되지 못했거나 Developer가 이를 잘못 이해해서 문제가 발생할 가능성인데, 이는 적을 수록 좋으나 언제나 발생할 가능성이 존재하며 이를 위해 지속적으로 문서화 하고 또 확인하는 작업을 계속 반복하게 된다.

requirements에 대해 불일치 가능성을 배제하며 불가능한 요구사항을 파악하고 그것을 전달하는 것이 Developer 의 First Mission 이다.

 

아래는 Allen의 피드백이다.

  • Requirement capture / understand

requirement는 보통 두가지로 분류된다.

  • functional requirements

    • 주로 use-case에 documented

      • 각각의 use-case에 대해서 성공적으로 기능을 수행할 수 있는가에 대한 요구사항
      • 이를 바탕으로 사용자가 하려고 하는 부분에 대해서 보다 "구체적"으로 정의

    • 중요 키워드 : coverage

  • nonfunctional requiremnts

    • performance, usability, platform support와 같은 기타 constraints
    • 모든 사항이 documneted 되어있지 않을 수 있기 때문에 다른 이해관계자stakeholder들과 communication하는 것이 중요
    • 중요키워드 : limits

  • 분류하여 접근하는 것이 요구사항을 정리/분석하고 이를 달성하고, 실제로 달성했는지 평가하는것에 도움을 준다.

 

  • Use-Case Realizations

요구사항 구체화를 수행할때 나온 class의 세가지 분류는 명사화뿐 아니라 해당 class가 어떤 기능에 focusing되어 있는지에 고민하는 것에 대해서 도움을 주며, 특히나 use case는 일반적으로 '문장'으로 구성되게 되는데 이 문장은 '명사'들 뿐만 아니라 동사나 다른 형태의 문장요소들을 포함하고 있다.

명사들을 어느정도 추출해 낸 후 각 명사들간의 관계나, 동작에 대한 부분을 표현하고자 할때 이런 분류법을 기반으로 적절한 class를 생각해내는 것은 좋은 접근법이니 함께 정리해보는 것이 좋다.

 

  • Distribute behavior to analysis classes , Detail analysis classes and unify the analysis model.

추출해낸 명사에 대해서 각각이 적합한 responsibility를 갖고 있는지 분석하고 롤을 재분배하는 작업으로 실제 적용하는 것은 경험적인 부분도 많이 작용하고 여러번 시도를 해보아야하는 어느정도 애매한 영역이 존재한다.

 

 

Design, implement, and test use cases and components

제공하기로 약속된 기능을 설계, 구현 및 테스트할 수 있는지 확인하라.

모든 목차중에 가장 많은 내용을 담고있는 부분이며 UML작성등이 여기에 포함될 수 있며 크게 아래의 작업으로 나뉜다.

  • Design Use-Case Realizations and Components

사용자가 요청한 Use-Case를 직접적으로 구현화 하는 일이다. 이 과정에서 실질적으로 UML과 같은 작업물들이 나올 수 있으며 이를 기반으로 Components의 분리나 Design이 시작된다. 이러한 과정은 아래의 Step들로 구성된다.

Step 1: Produce a first-draft outline for what analysis objects are needed to provide the collaboration.

Step 2: Distribute behavior to analysis classes.

Step 3: Detail analysis classes and unify the analysis model.

Step 4: Do use-case design.

Step 5: Detail each design class and unify the design model.

또한 저자가 마무리 단계인 Step 5 에서

When designing classes, keep in mind established design patterns, such as the so-called Gang of Four patterns. You may find these and other patterns useful for solving common design problems.

라는 말이 나오는데 이를 통해 이 과정에서 Design Pattern이 중요하다는걸 알 수 있으며 명사를 뽑거나 하는 과정도 이에 포함된다.

 

  • Implement Use-Cases and Components

위 과정을 통해 Design된 작업물을 기반으로 실질적으로 실행 가능한 Use-Case와 Components를 작성하며, 이 과정에서 나오는 작업물등에는 소스코드와 실행파일등이 있다.

 

  • Developer Testing

실행가능한 소스코드와 실행파일을 User Feedback을 포함해서 지속적인 Testing을 해야한다.

 

위 세가지 일들은 어찌보면 당연하다고 할 수 있지만 실무에서 무시되는 경우가 존재하며 이 순서가 역순이 되는 경우가 발생할 수 있다.

RUP에서는 이를 방지하기 위한 장치들은 앞서 서술되어 있으며 특히 "Design Use-Case Realizations and Components" 은 이후 전반적인 모든 Task에 영향을 주기 때문에 많은 주의가 필요하다. 특히 위에서 말한데로 Design Pattern에 대해 유념하여 작성하는 것 또한 중요하다.

 

Design, implement, and test any necessary databases

대부분의 시스템에는 데이터베이스가 있으며, 당신은 얼마나 영구적인 데이터가 데이터베이스에 저장되고 데이터베이스에서 검색되는지를 이해해야 한다.

사실 이 부분은 위에서 말한 것과 같이 요구사항에 대해서 구현 및 설계가 되어 있어야 하며, 이를 이해관계자들이 이해할 수 있게 작성되어야 한다는 것이다.

특히 여기서 중요하게 봐야할 부분은 "영구적인" 이라는 말인데, 이는 그만큼 위와 다르게 지우거나 변경하기 어렵다는 말이므로 초반에 확실하게 정의 해서 작성하는 것이 중요하다. 그리고 여기서 강조하는 것이 있는데, 바로 성능 테스트를 지원가능해야 하며 그 결과를 기초로 하여 데이터 모델을 최적화 할 수 있는 환경을 같이 생각해서 Design되어야 한다는 것이다.

 

즉, 데이터베이스 또한 테스트 가능한 환경 자체가 중요한 역할이라는 것을 알 수 있다.

 

Frequently integrate your application with the work of other developers

반복 개발을 수행할 때 응용 프로그램의 빈번한 통합은 핵심 원칙이다.

저자는 여기서 Build 와 Release 의 명확한 차이를 두며, Build 는 자주할 수록 좋고 많이 통합 할 수록 좋다고 서술한다. Build 를 자주 함으로써 Final Release 와 더 가까워지고 이는 더 많은 그리고 안정적인 Release 를 다시 배포 할 수 있음을 뜻한다.

A build demonstrates a subset of the capabilities to be provided in the final product-

"A build is not, however, the same as a release"

또 이 작업에 대해서 비용이라는 말을 많이 사용하는데 여기서 "Configuration Management System"이라는 단어(?)가 나온다. 이것이 말하고 싶은 내용은 위에 처럼 자주 통합하면 좋지만 그에 따른 Cost가 분명히 존재하며 이는 규모가 커질 수록 감당할 수 없을 것이다.

즉 "배보다 배꼽이 더 큰 상황"이 나올 수도 있다는 것이다.

A good Configuration Management system with support for automated build management can significantly reduce the cost of doing frequent builds.

그렇기 때문에 저자는 "Configuration Management System"을 강조했다.

 

Configuration Management Workspace

이러한 번번한 통합을 하기 위해서는 Workspace에 대한 독립성과 통일성이 유지되어야 하는데 이것을 관리하는 작업 또한 큰 규모일 경우 필요한 일이라는 것이라는 이야기이다.

A workspace provides each project member with an environment that selects and presents the appropriate version of each file.

여기서 "독립성"은 빌드 및 테스트에 대한 캡슐화를 뜻하며 나의 빌드 작업물이 다른 사람에게 또한 내 작업물이 다른 사람의 작업으로 변경되지 않는 것을 뜻하며, "통일성"은 통합할 때 환경에 따른 차이가 없게 유지하는 것을 말한다.

 

일반적인 UP의 phase 및 각각에서의 산출물/작업

엘렌의 피드백을 기반으로 추가하였다.

 

각 phase별 milestone

  • inception -> Vision & scope. 전체적인 시스템에 대한 요구사항 식별 및 범위, 기한 등을 산정

  • Ellabolation -> Baseline Architecture (실제 노력 투자 하여 시스템의 설계)

  • Construction -> Initial Capability (실제 구현)

  • Transition -> product release

     

  1. Requirement Capture

    1. UseCase Diagram

      1. 전체 동작에 필요한 Actor와 System을 정의하고 Actor가 System을 사용하는 Service 별로 Use Case를 정리한다.

    2. UseCase Description

      1. a에서 정리한 case 하나하나를 선택하여 각각에 대하여 actor, 동작의 목적, 필요한 요구 사항들을 정리한다.
      2. 각 case의 목적이나 OverView를 정리할 때에는 Actor의 관점에서(System 외부의 관점에서) 어떠한 작업들이 이루어지는지 하나씩 정리한다.
      3. 이 Use Case와 연관성을 갖는 기능이나 Use case들을 Reference로 정리한다.

    3. Usecase Detail Description(Typical Course of Events)

      1. 전체적인 동작 내용들을 Actor와 System에서의 동작으로 분리하여 순서대로 정리한다.

      2. 예외조건을 제외하고 일반적인 상황에서의 시나리오를 정리하는데 이때 event들을 정리한다.

         

  2. Analysis

    1. Conceptual Modeling - Conceptual Model

      1. UseCase에서 사용된 ‘명사’를 중심으로 전체적인 시스템에서 사용되는 모델들(class)과 attribute들을 뽑는다.

    2. Finding Association - Conceptual Model

      1. Model들 간의 관계를 선을 그어 표현한다.
      2. 지나치게 많은 연관관계는 전체적인 concept을 이해하는데 혼란을 발생시킬 수 있으니 중복되는, 불필요한 관계들을 표현하는 것은 피한다.

    3. Contract

      1. 시스템이 반드시 해야할 작업들을 정리

      2. 어떻게 해당 작업이 이루어지는가보다는 무엇을 하고 그것을 위한 사전 상태와 결과를 중심적으로 정리한다.

         

  3. Design

    1. Interaction Diagrams & Collaboration Diagram

      1. 각 작업을 완료하기 위하여 Object들이 어떤 message를 주고 받으며 동작하는지 정리한다.
      2. 전체적인 시스템의 Object들의 Behavior를 정의한다.

    2. Class Diagram - Class Diagram

      1. 전체적인 구조를 Presentation layer와 Domain Layer로 분리하여 생각한다.
      2. Presentation Layer에서는 오직 사용자가 사용하게 될 인터페이스나 UI와 관련된 부분만을 담당하도록 한다.
      3. Presentaion Layer에서 실제 업무상 필요한 request를 처리할 Domain Layer에 전달한다.
      4. DomainLayer에서는 실제 기능적으로 필요한 부분들을 처리하도록 한다.

각 phase,step 작업 별로 적절한 산출물을 만들고 다음 step에서 "그 산출물을 활용하는것"이 UP의 핵심이기도 합니다. 그러나 그 산출물을 모두 만드는 것은 "매우 많은 overhead가 발생"하기 때문에 어느정도 조정을 하면서 실무적으로 진행하게 될 예정입니다.

생략한 산출물로 인해 오히려 다음 스텝 진행이 어렵다고 느껴지는 경우(또는 생략이 불가하다고 느껴지는 경우) 간략하게라도 이전 스텝에 대한 리스트업/문서화를 진행할 수 있습니다.

 

마무리

이 이후는 Developer Best Practices나 Refactor Your Code and Design, Pair Programming과 같은 방법들을 제시하는 부분이며 휴먼 에러를 최소할 수 있는 여러가지 방법들을 추가로 제시한다.

RUP 책은 이렇게 마무리 되며 Design Pattern과 같은 부분은 따로 정리하기 위해 일부러 조금 생략한 부분도 존재한다. Clean Architecture 를 보았던 것이 많은 도움이 되었으며, 이 책은 Architecture의 더 윗부분- 즉 제품을 만드는 전체적인 관점에서 볼 수 있게 해주는 책인거 같다.

 

현재 이 책에 대한 정리는 Developer에 대한 Role만 정리했지만 Tester나 Project Manager의 역할에 대한 Guide도 제시하고 있으며 같은 Developer도 내부적으로 또 RUP에서 제공하는 역할이 더 다양하게 나누어져 있고 그에 따른 Guide또한 또 세부사항으로 존재한다.

 

저작자표시 변경금지 (새창열림)

'Study' 카테고리의 다른 글

Clean Architecture(옮기는 중)  (0) 2020.10.20
'Study' Related Articles more
Comments