맨위로가기

래셔널 통합 프로세스

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

래셔널 통합 프로세스(RUP)는 래셔널 소프트웨어에서 개발되었으며, 2003년 IBM에 인수된 소프트웨어 프로세스 제품이다. RUP는 역할, 작업 산출물, 태스크를 기반으로 하며, 도입, 상세, 구축, 이행의 4단계 생명 주기를 정의한다. RUP는 반복적 개발, 요구 사항 관리, 컴포넌트 기반 아키텍처, 시각적 모델링, 품질 검증, 변경 관리의 6가지 우수 실천 방법을 제시하여 소프트웨어 개발의 효율성을 높인다. IBM은 RUP를 기반으로 애자일 프로젝트에 맞춘 OpenUP을 개발하기도 했다.

더 읽어볼만한 페이지

  • 소프트웨어 프로젝트 관리 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
  • 소프트웨어 프로젝트 관리 - 애자일 소프트웨어 개발
    애자일 소프트웨어 개발은 1990년대에 등장하여 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 핵심 가치로 삼고 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구하는 소프트웨어 개발 방법론이다.
  • 소프트웨어 개발 - 유스 케이스
    유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다.
  • 소프트웨어 개발 - 사용자 경험 디자인
    사용자 경험 디자인은 인간 공학에 기반하여 제품 또는 서비스와 사용자 간의 상호작용을 설계하는 분야이며, 사용자 조사, 인터랙션 디자인, 사용성 테스트 등을 통해 효율적이고 만족스러운 경험을 제공하는 것을 목표로 한다.
  • IBM 소프트웨어 - IBM 시스템 R
  • IBM 소프트웨어 - PL/I
    PL/I는 1960년대 IBM이 과학 및 상업 분야의 다양한 프로그래밍 요구를 위해 개발한 고급 프로그래밍 언어로, 포트란, 코볼, 알골의 특징을 융합하여 시스템 프로그래밍, 이벤트 기반 프로그래밍 등 다양한 분야에 사용될 수 있도록 설계되었다.
래셔널 통합 프로세스
개요
종류소프트웨어 개발 프로세스
개발자래셔널 소프트웨어 공사 (현 IBM)
발표일1998년
특징
중심아키텍처 중심, 반복적, 점진적
단계착수 (Inception)
정교 (Elaboration)
구축 (Construction)
이행 (Transition)
워크플로비즈니스 모델링
요구사항
분석 및 설계
구현
테스트
배치
구성 및 변경 관리
프로젝트 관리
환경
관련
언어UML
참고 서적The Unified Software Development Process by Ivar Jacobson, Grady Booch and James Rumbaugh
The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP by Per Kroll and Philippe Kruchten

2. 역사

래셔널 소프트웨어는 래셔널 통합 프로세스(RUP)라는 소프트웨어 프로세스 제품을 개발했다. 2003년 2월, IBM에 인수되었으며, 현재는 IBM 래셔널 메소드 컴포저(RMC) 제품에 포함되어 프로세스 사용자 정의를 지원한다.[2] RUP는 다양한 활동에 대한 샘플 아티팩트와 자세한 설명을 담은 하이퍼링크된 지식 기반을 포함한다.

1997년부터 2003년까지 래셔널 소프트웨어와 IBM은 RUP를 지속적으로 발전시켰다. 특히, 애자일 방법론을 수용하여 변화하는 개발 환경에 유연하게 대처할 수 있도록 개선했다.

2. 1. 개발 배경

래셔널 소프트웨어는 객체지향 시스템 구축 경험과 유스케이스 중심의 Objectory 방법론, 짐 럼보(Jim Rumbaugh)의 객체 모델링 기술(OMT), 그래디 부치(Grady Booch)의 부치 방법론, 그리고 초기 통합 모델링 언어(UML)를 통합하여 RUP를 개발했다.[2][3] 필립 크루첸(Philippe Kruchten)은 RUP 개발 팀을 이끌며, 현대 소프트웨어 엔지니어링을 위한 명시적인 프로세스 프레임워크를 구성하는 데 기여했다.

1997년, 래셔널은 여러 회사들을 인수하며, 이 회사들의 경험을 바탕으로 현대 소프트웨어 공학의 여섯 가지 우수 교훈들을 선정하였다.

  • 발견된 위험 요소를 원동력으로 반복적으로 개발하라.
  • 필수사항을 관리하라.
  • 컴포넌트 기반의 구조를 도입하라.
  • 소프트웨어를 시각화하라.
  • 품질을 지속적으로 확인하라.
  • 변화를 통제하라.


이러한 우수 교훈을 바탕으로 래셔널은 제품들을 개발하고, 고객들의 소프트웨어 개발 품질과 예측성을 높였다. 필립 크루첸은 이러한 지식을 쉽게 접근할 수 있도록 Objectory의 HTML 기반 프로세스 전달 메커니즘을 적용하여 RUP를 만들었다. RUP는 다음과 같은 래셔널의 세 가지 전략적인 목표를 완수했다.

  • 개발을 돕는 ''맞춤형 프로세스''
  • 이 프로세스를 자동으로 적용하는 ''도구''
  • 프로세스와 도구를 쓰도록 촉진하는 ''서비스''


1998년에는 비즈니스 모델링과 구성 및 변경 관리, 1999년에는 프로젝트 관리 규율이 추가되었다. 또한, 이바 야콥슨, 그래디 부치, 제임스 럼보의 ''The Unified Software Development Process''가 출판되었다.

2000년부터 2003년 사이에는 익스트림 프로그래밍(XP)과 같은 애자일 방법론의 개념과 기술이 도입되었다. 2006년 IBM은 애자일 프로젝트 제공을 위해 RUP의 하위 집합을 만들어 이클립스 웹 사이트를 통해 OpenUP라는 오픈 소스 방법으로 출시했다.[5]

2. 2. 발전 과정

1997년, 래셔널은 여러 회사를 인수하며 요구사항 및 테스트, 형상 관리 등의 분야를 RUP에 통합했다. 이 과정에서 래셔널은 현대 소프트웨어 공학의 여섯 가지 우수 교훈을 선정했다.

  • 발견된 위험 요소를 원동력으로 반복적으로 개발하라.
  • 필수사항을 관리하라.
  • 컴포넌트 기반의 구조를 도입하라.
  • 소프트웨어를 시각화하라.
  • 품질을 지속적으로 확인하라.
  • 변화를 통제하라.


이러한 우수 교훈은 래셔널 제품 개발의 기반이 되었고, 필립 크루첸은 이 지식을 바탕으로 현대 소프트웨어 공학에 맞는 프로세스 프레임워크를 종합하여 RUP를 만들었다.

1998년에는 비즈니스 모델링과 구성 및 변경 관리 규율이 추가되었다. 비즈니스 모델링은 Objectory 프로세스에 이미 포함되어 있었고, 구성 및 변경 관리는 퓨어 아트리아(Pure Atria)사 인수를 통해 추가되었다.

1999년에는 프로젝트 관리 규율이 도입되었고, 실시간 소프트웨어 개발 지원 및 UML 1.3 반영을 위한 기술이 추가되었다. 또한, 이바 야콥슨, 그래디 부치, 제임스 럼보의 ''The Unified Software Development Process''가 출판되었다.

2000년부터 2003년까지는 익스트림 프로그래밍(XP)의 개념과 기술을 도입하여 애자일 방법론과의 융합을 시도했다. 테스트 규율을 전면 개편하고, RUP 실천 방법을 실행하기 위한 "도구 멘토"를 도입했다. 또한 RUP 사용자 정의를 자동화하여 고객이 프로세스 프레임워크의 일부를 선택하고 자체 추가 사항으로 사용자 정의할 수 있도록 했다.

2006년, IBM은 애자일 프로젝트를 위한 RUP의 하위 집합인 OpenUP을 오픈 소스로 출시했다.[5]

3. RUP의 구성 요소

RUP는 역할(Who), 작업 산출물(What), 태스크(How)라는 세 가지 주요 구성 요소를 기반으로 한다. RUP는 무엇을 생산해야 하는지, 필요한 기술은 무엇인지, 특정 개발 목표를 달성하는 방법을 단계별로 설명한다.[1]

3. 1. 역할 (Who)

역할은 관련된 기술, 역량 및 책임의 집합을 정의한다.

3. 2. 작업 산출물 (What)

작업 산출물은 프로세스가 진행되는 동안 생산되는 모든 문서 및 모델을 포함하여 작업의 결과물을 나타낸다.[1]

3. 3. 태스크 (How)

태스크는 의미 있는 결과를 제공하는 역할에 할당된 작업 단위를 설명한다.[1] 각 반복 내에서 태스크는 9가지 분야로 분류된다.[1]

  • 6개의 "엔지니어링 분야"
  • 비즈니스 모델링
  • 요구사항
  • 분석 및 설계
  • 구현
  • 테스트
  • 배포
  • 3개의 지원 분야
  • 형상 및 변경 관리
  • 프로젝트 관리
  • 환경

4. RUP의 생명 주기

RUP 단계와 분야.


RUP는 도입(Inception), 상세(Elaboration), 구축(Construction), 이행(Transition)의 4단계로 구성된 프로젝트 생명 주기를 정의한다. 각 단계는 주요 목표와 이정표를 가지며, '폭포수' 방식과 유사하게 프로젝트를 높은 수준에서 제시하지만, 모든 단계 내에서 개발이 반복된다는 점이 핵심이다. RUP 단계와 분야의 시간 경과에 따른 시각화를 RUP 험프 차트라고 한다.

4. 1. 도입 단계 (Inception)

도입 단계의 주요 목표는 시스템의 범위를 적절하게 파악하여 초기 비용 및 예산을 검증하기 위한 기반을 마련하는 것이다.

이 단계에서는 비즈니스 컨텍스트, 성공 요인(예상 수익, 시장 인지도 등), 재무 예측을 포함하는 사업 타당성 분석이 이루어진다. 사업 타당성 분석을 보완하기 위해 기본적인 유스 케이스 모델, 프로젝트 계획, 초기 위험 평가 및 프로젝트 설명(핵심 프로젝트 요구 사항, 제약 조건 및 주요 기능)이 생성된다.

이러한 작업이 완료되면, 프로젝트는 다음 기준에 따라 검토된다.

  • 이해 관계자의 범위 정의 및 비용/일정 추정에 대한 합의.
  • 주요 유스 케이스의 충실도를 통해 입증된 요구 사항 이해.
  • 비용/일정 추정, 우선 순위, 위험 및 개발 프로세스의 신뢰성.
  • 개발된 아키텍처 프로토타입의 깊이와 폭.
  • 예상 지출과 실제 지출을 비교할 수 있는 기준선 설정.


프로젝트가 이러한 생명 주기 목표 마일스톤을 통과하지 못하면, 프로젝트는 취소되거나, 기준을 더 잘 충족하도록 재설계된 후 다시 수행될 수 있다.[1]

4. 2. 상세 단계 (Elaboration)

상세 단계는 프로젝트가 형태를 갖추기 시작하는 단계이다. 이 단계에서는 문제 도메인 분석이 이루어지고 프로젝트의 아키텍처가 기본적인 형태를 갖추게 된다.[1]

상세 단계의 결과는 다음과 같다.[1]

  • 사용 사례와 액터가 식별되고 대부분의 사용 사례 설명이 개발된 사용 사례 모델. 사용 사례 모델은 80% 완료되어야 한다.
  • 소프트웨어 시스템 개발 프로세스에서 소프트웨어 아키텍처에 대한 설명.
  • 아키텍처적으로 중요한 사용 사례를 실현하는 실행 가능한 아키텍처.
  • 수정된 사업 사례 및 위험 목록.
  • 전체 프로젝트에 대한 개발 계획.
  • 식별된 각 기술적 위험을 확실하게 완화하는 프로토타입.
  • 예비 사용자 설명서(선택 사항)


이 단계는 다음 질문에 답하는 수명 주기 아키텍처 마일스톤 기준을 통과해야 한다.[1]

  • 제품의 비전은 안정적인가?
  • 아키텍처는 안정적인가?
  • 실행 가능한 데모는 주요 위험 요소가 해결되고 해결되었음을 나타내는가?
  • 구축 단계 계획은 충분히 상세하고 정확한가?
  • 모든 이해 관계자는 현재 아키텍처의 맥락에서 현재 계획을 사용하여 현재 비전을 달성할 수 있다는 데 동의하는가?
  • 실제 vs. 계획된 자원 지출은 허용 가능한가?


프로젝트가 이 마일스톤을 통과하지 못하면 취소하거나 재설계할 시간이 여전히 있다. 그러나 이 단계를 벗어난 후 프로젝트는 변경이 훨씬 더 어렵고 해로운 고위험 작업으로 전환된다.[1]

상세 단계를 위한 주요 도메인 분석은 시스템 아키텍처이다.[1]

5. RUP의 6가지 우수 실천 방법

RUP는 소프트웨어 프로젝트의 결함을 최소화하고 생산성을 높이기 위해 다음과 같은 6가지 우수 실천 방법을 제시한다.[9][10]


  • 반복적 개발: 변화하는 요구사항에 유연하게 대응한다.
  • 요구사항 관리: 사용자가 설정한 요구 사항을 항상 염두에 둔다.
  • 컴포넌트 기반 아키텍처: 시스템을 독립적인 컴포넌트로 나누어 개발하고 재사용성을 높인다.
  • 시각적 모델링: 통합 모델링 언어(UML) 등을 사용하여 시스템을 시각적으로 표현한다.
  • 품질 검증: 지속적인 테스트를 통해 소프트웨어 품질을 확보한다.
  • 변경 관리: 여러 팀과 플랫폼에서 발생하는 변경 사항을 체계적으로 관리한다.

5. 1. 반복적 개발 (Iterative Development)

변화하는 요구사항에 유연하게 대응하기 위해 반복적인 개발을 수행한다. 모든 요구 사항을 미리 파악하는 것이 이상적이지만, 현실적으로 어려운 경우가 많다. 따라서 여러 소프트웨어 개발 프로세스들은 개발 단계에서 비용을 최소화하는 해결책을 제공하기 위해 노력한다.[9][10]

5. 2. 요구사항 관리 (Requirements Management)

사용자는 항상 자신이 설정한 요구 사항을 염두에 두어야 한다.[9][10]

5. 3. 컴포넌트 기반 아키텍처 (Component-Based Architecture)

컴포넌트 기반 아키텍처는 소프트웨어 프로젝트에서 결함을 최소화하고 생산성을 높이기 위해 정의된 6가지 최고의 소프트웨어 공학 관행 중 하나이다.[9][10] 고급 프로젝트를 분해하는 것은 권장될 뿐만 아니라 실제로 불가피하다. 이는 더 큰 시스템에 통합되기 전에 개별 컴포넌트를 테스트하는 능력을 촉진한다. 또한 코드 재사용은 큰 장점이며 객체 지향 프로그래밍을 통해 더 쉽게 달성할 수 있다.

5. 4. 시각적 모델링 (Visual Modeling)

통합 모델링 언어(UML)의 약자인 "UML"과 같은 다이어그램을 사용하여 모든 주요 컴포넌트, 사용자 및 상호 작용을 나타낸다. 이러한 시각적 모델링은 시스템 설계를 돕고, 이해 관계자 간의 의사소통을 원활하게 한다.[9][10]

5. 5. 품질 검증 (Quality Verification)

소프트웨어 공학의 6가지 최고의 관행(반복 개발, 요구 사항 관리, 컴포넌트 사용, 시각적 모델링, 변경 관리) 중 하나로, 프로젝트의 주요 부분으로 언제든지 테스트를 수행한다.[9][10] 프로젝트가 진행됨에 따라 테스트는 더 강화되지만, 모든 소프트웨어 제품 생성에서 지속적으로 이루어져야 한다. 이를 통해 소프트웨어 품질을 확보하고 결함을 조기에 발견할 수 있다.

5. 6. 변경 관리 (Change Management)

여러 프로젝트는 다양한 위치의 여러 팀에 의해 생성되며, 서로 다른 플랫폼을 사용할 수 있다. 따라서 시스템에 가해지는 변경 사항이 동기화되고 지속적으로 검증되도록 하는 것이 중요하다.[9][10] (지속적 통합 참고).

6. 관련 도구

IBM 래셔널 메소드 컴포저는 프로세스를 작성, 구성, 열람 및 게시하기 위한 도구이다. 이클립스 프로세스 프레임워크 (EPF)는 오픈 소스 버전이다.[1]

참조

[1] 웹사이트 IBM Acquires Rational http://www.eweek.com[...]
[2] 웹사이트 The Rational Objectory Process - A UML-based Software Engineering Process http://www.iscn.at/s[...] Rational Software Scandinavia AB 2014-12-17
[3] 서적 The Rational Unified Process: An Introduction https://books.google[...] Addison-Wesley 2014-12-17
[4] 웹사이트 RUP in brief http://www.ibm.com/d[...] IBM 2011-07-12
[5] 웹사이트 OpenUP http://epf.eclipse.o[...] 2013-08-03
[6] 웹사이트 The value of RUP certification http://www.ibm.com/d[...] IBM 2014-05-05
[7] 웹사이트 Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0 http://www-03.ibm.co[...] IBM 2008-05-13
[8] 웹사이트 Test 839: Rational Unified Process v7.0 http://www-03.bm.com[...] IBM 2008-05-13
[9] 서적 Classical and Object-Oriented Software Engineering WCB McGraw Hill 2004
[10] 간행물 Rational Unified Process white paper http://www.augustana[...] 2009-05-01
[11] 웹사이트 Testing: The RUP Philosophy https://www.academia[...] Rational Software (Rational Edge e-zine) 2003-02


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com