합리적인 통합 프로세스

Rational Unified Process
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

RUP(Rational Unified Process)는 2003년 [1]이후 IBM의 사업부인 Rational Software Corporation에서 만든 반복적인 소프트웨어 개발 프로세스 프레임워크입니다.RUP는 하나의 구체적인 규범적 프로세스가 아니라 적응 가능한 프로세스 프레임워크로 개발 조직과 소프트웨어 프로젝트 팀이 필요에 따라 프로세스의 요소를 선택할 수 있도록 맞춤 제작되었습니다.RUP는 통합 프로세스의 특정 구현입니다.

역사

Rational Software는 원래 소프트웨어 프로세스 제품으로 합리적인 통합 프로세스를 개발했습니다.이 제품에는 다양한 유형의 활동에 대한 샘플 아티팩트와 자세한 설명이 포함된 하이퍼링크 기술 자료가 포함되어 있습니다.RUP는 프로세스를 사용자 정의할 수 있는 IBM RMC(Rational Method Composer) 제품에 포함되어 있습니다.

Rational의 숙련된 기술 대표인 Philippe Kruchten은 원래 RUP 팀을 이끄는 임무를 맡았다.

이러한 초기 버전은 Rational Software 조직의 광범위한 현장 경험(Rational 현장 직원이 Rational 접근법이라고 함)과 사용 사례 등의 실무에 대한 Objectory의 지침을 결합하고 Jim Rumbaugh의 객체 모델링 기술(OMT) 접근법의 광범위한 콘텐츠를 통합했습니다.모델링, Grady Boch의 Booch 방식, 그리고 새로 출시된 UML 0.[2][3]8입니다.

Philippe Kruchten은 이 늘어나는 지식 기반에 보다 쉽게 접근할 수 있도록 하기 위해 현대 소프트웨어 엔지니어링을 위한 명시적 프로세스 프레임워크를 조립하는 임무를 맡았습니다.이 작업에는 Objectory가 개발한 HTML 기반 프로세스 전달 메커니즘이 사용되었습니다.그 결과, 「RUP(Rational Unified Process)」는, Rational의 전략적인 삼각대를 완성했습니다.

  • 개발을 이끈 조정 가능한 과정
  • 그 프로세스의 적용을 자동화한 툴
  • 프로세스와 툴의 도입을 가속화한 서비스입니다.

이 가이던스는 Rational이 인수한 회사의 경험을 바탕으로 한 지식을 바탕으로 후속 버전에서 강화되었습니다.

1997년에는 Requisite, Inc.의 Dean Leffingwell 등이 개발한 Requisite College 방법과 SQA Inc.에서 개발한 SQA 프로세스 방법에서 많은 추가 자료들이 Rational Software에 인수되었다.

1998년에 Rational Software는 두 가지 새로운 분야를 추가했습니다.

  1. 비즈니스 모델링, 이 콘텐츠의 대부분은 이미 객체화 프로세스에 포함되어 있었습니다.
  2. 구성 및 변경 관리 규율은 Pure Atria Corporation 인수를 통해 조달됩니다.

이러한 추가에 의해 Rational에 의해 정의되고 RUP 내에서 현대적인 소프트웨어 엔지니어링의 6가지 베스트 프랙티스로 표현된 중요한 일련의 원칙이 도출됩니다.

  1. 리스크가 주된 반복[4] 요인인 반복 개발
  2. 요건 관리
  3. 컴포넌트 기반 아키텍처 채택
  4. 시각적으로 소프트웨어 모델링
  5. 지속적인 품질 검증
  6. 변경 제어

이러한 베스트 프랙티스는 Rational의 제품 라인과 밀접하게 연계되어 Rational의 지속적인 제품 개발을 주도할 뿐만 아니라 Rational의 현장 팀이 소프트웨어 개발 작업의 품질과 예측 가능성을 향상시키는 데에도 활용되었습니다.

성능 테스트, UI 설계, 데이터 엔지니어링, UML 1.1의 변경 사항을 반영하기 위한 업데이트 등의 추가 기술이 포함되었습니다.

1999년에는 UML 1.3을 반영하여 실시간 소프트웨어 개발 및 업데이트를 지원하는 기술뿐만 아니라 프로젝트 관리 분야가 도입되었습니다.또한 프로세스를 설명하는 첫 번째 책인 통합 소프트웨어 개발 프로세스( ISBN0-201-57169-2)는 같은 해에 발행되었습니다.

2000년과 2003년 사이에는 RUP 인스턴스 제정 및 RUP 프레임워크 맞춤을 위한 도구 지원과 더불어 반복 개발에 대한 지속적인 Rational 현장 경험에서 많은 변경이 도입되었다.변경 내용은 다음과 같습니다.

  1. eXtreme Programming(XP)과 같은 접근 방식에서 개념과 기술을 도입하여 나중에 총칭하여 민첩한 방법으로 알려지게 되었습니다.여기에는 페어 프로그래밍, 테스트 우선 설계, 대규모 프로젝트에서 사용하기 위해 어떻게 XP를 확장할 수 있었는지 설명한 논문 등의 기술이 포함되어 있습니다.
  2. 다양한 반복적인 개발 맥락에서 테스트 작업이 어떻게 수행되었는지를 더 잘 반영하기 위해 테스트 분야의 완전한 정비.
  3. 다양한 도구에서 RUP 프랙티스를 제정하기 위한 "도구 멘토"로 알려진 지원 지침의 도입.이는 기본적으로 Rational 툴 사용자에게 단계별 메서드 지원을 제공합니다.
  4. 고객이 RUP 프로세스 프레임워크에서 부품을 선택하고 자체 추가 기능으로 선택 항목을 맞춤화할 수 있도록 RUP의 커스터마이즈를 자동화하며 Rational의 후속 릴리스에도 개선 사항을 포함시킬 수 있습니다.

IBM은 2003년 2월에 Rational Software를 인수했습니다.

2006년 IBM은 신속한 변화를 위한 프로젝트 제공에 적합한 RUP 서브셋을 만들었습니다. 이 서브셋은 OpenSource 방식으로 출시되었습니다.Eclipse 웹 [5]사이트를 참조하십시오.

합리적인 통합 프로세스 토픽

RUP 구성 요소

RUP는 일련의 구성요소와 콘텐츠 요소를 기반으로 생산 대상, 필요한 기술 및 특정 개발 목표를 달성하는 방법을 설명하는 단계별 설명을 제공합니다.주요 구성 요소 또는 내용 요소는 다음과 같습니다.

  • 역할(누구)– 역할이란 관련된 기술, 능력 및 책임을 정의합니다.
  • 작업 제품(무엇) – 작업 제품은 작업 과정에서 생성된 모든 문서와 모델을 포함하여 작업 결과물을 나타냅니다.
  • 태스크(방법) – 태스크는 의미 있는 결과를 제공하는 역할에 할당된 작업 단위를 나타냅니다.

각 반복에서 태스크는 9개의 분야로 분류됩니다.

4가지 프로젝트 라이프 사이클 단계

RUP 단계 및 분야

RUP는 4단계로 구성된 프로젝트의 라이프 사이클을 결정하였습니다.이러한 단계를 통해 '폭포' 스타일의 프로젝트가 어떻게 제시될 수 있는지와 유사한 방식으로 프로세스를 높은 수준으로 제시할 수 있습니다. 단, 프로세스의 핵심은 본질적으로 모든 단계에 포함되는 개발의 반복에 있습니다.또한 각 단계에는 달성된 목표를 나타내는 하나의 핵심 목표와 이정표가 마지막에 있습니다.시간 경과에 따른 RUP 단계 및 분야를 시각화하는 것을 RUP 혹 차트라고 합니다.

개시 단계

주요 목표는 초기 비용과 예산을 검증하기 위한 기준으로 시스템을 적절히 적용하는 것입니다.이 단계에서는 비즈니스 컨텍스트, 성공 요인(예상 수익, 시장 인식 등) 및 재무 예측을 포함하는 비즈니스 케이스를 확립한다.비즈니스 케이스를 보완하기 위해 기본 활용 사례 모델, 프로젝트 계획, 초기 리스크 평가 및 프로젝트 설명(핵심 프로젝트 요건, 제약 조건 및 주요 기능)을 생성합니다.이 작업이 완료되면 프로젝트는 다음 기준에 따라 검사됩니다.

  • 범위 정의 및 비용/스케줄 견적에 대한 이해관계자 동의
  • 주요 사용 사례의 충실도를 통해 입증되는 요구사항 이해
  • 비용/스케줄 견적, 우선순위, 리스크 및 개발 프로세스의 신뢰성.
  • 개발된 모든 아키텍처 프로토타입의 깊이와 폭.
  • 실제 지출과 계획된 지출을 비교하는 기준선을 확립한다.

프로젝트가 라이프 사이클 목표 마일스톤이라고 불리는 이 마일스톤을 통과하지 못할 경우 기준을 보다 잘 충족하도록 재설계한 후 취소하거나 반복할 수 있습니다.

상세 단계

주요 목표는 분석을 통해 식별된 주요 위험 항목을 이 단계가 끝날 때까지 완화하는 것이다.상세화 단계는 프로젝트가 구체화되기 시작하는 단계입니다.이 단계에서는 문제 영역의 분석이 이루어지고 프로젝트의 아키텍처가 기본 형태를 갖습니다.

상세 단계의 결과는 다음과 같습니다.

  • 활용 사례와 행위자가 식별되고 대부분의 활용 사례 설명이 개발된 활용 사례 모델.사용 사례 모델은 80% 완성되어야 합니다.
  • 소프트웨어 시스템 개발 프로세스의 소프트웨어 아키텍처에 대한 설명입니다.
  • 아키텍처상 중요한 사용 사례를 실현하는 실행 가능한 아키텍처.
  • 수정된 비즈니스 사례 및 리스크 리스트.
  • 프로젝트 전체의 개발 계획.
  • 확인된 각 기술적 위험을 명확하게 완화하는 프로토타입.
  • 예비 사용자 매뉴얼(옵션)

이 단계에서는 라이프 사이클 아키텍처의 마일스톤 기준을 통과하여 다음 질문에 답해야 합니다.

  • 제품의 시력은 안정되어 있습니까?
  • 아키텍처는 안정적입니까?
  • 실행 가능한 데먼스트레이션은 주요 위험 요소를 해결하고 해결했음을 나타냅니까?
  • 시공 단계 계획이 충분히 상세하고 정확한가?
  • 현재 아키텍처의 맥락에서 현재의 계획을 사용하여 현재의 비전을 달성할 수 있다는 데 모든 관계자가 동의하고 있습니까?
  • 실제 자원 지출과 계획된 자원 지출은 허용 가능한가?

프로젝트가 이 마일스톤을 통과할 수 없는 경우에도 취소하거나 재설계할 수 있습니다.그러나 이 단계를 벗어나면 변경은 훨씬 더 어렵고 해로울 수 있는 고위험 운영으로 전환됩니다.

상세한 설명을 위한 주요 도메인 분석은 시스템 아키텍처입니다.

건설 단계

주된 목적은 소프트웨어 시스템을 구축하는 것입니다.이 단계에서는 시스템의 컴포넌트 및 기타 기능의 개발에 중점을 두고 있습니다.이것은 대부분의 코딩이 이루어지는 단계입니다.대규모 프로젝트에서는 사용 사례를 관리 가능한 세그먼트로 나누어 시연 가능한 프로토타입을 제작하기 위해 여러 개의 건설 반복을 개발할 수 있습니다.

이행 단계

주요 목표는 시스템을 개발에서 실제 가동으로 '전환'하여 최종 사용자가 시스템을 사용할 수 있고 이해할 수 있도록 하는 것입니다.이 단계의 액티비티에는 최종사용자와 유지보수자에 대한 트레이닝과 최종사용자의 기대와 대조하여 시스템을 검증하는 베타 테스트가 포함됩니다.시스템은 평가 단계도 거칩니다.필요한 작업을 수행하지 않은 개발자는 교체 또는 제거합니다.이 제품은 Inception 단계에서 설정된 품질 수준과 대조됩니다.

모든 목표가 달성되면 제품 출시 마일스톤에 도달하고 개발 사이클이 종료됩니다.

IBM Rational Method Composer 제품

IBM Rational Method Composer 제품은 프로세스를 작성, 구성, 보기 및 게시하기 위한 도구입니다.자세한 내용은 IBM Rational Method Composer 및 EPF(오픈 소스 버전 Eclipse Process Framework) 프로젝트를 참조하십시오.

인정.

2007년 1월 IBM Certified Solution Designer - Rational Unified Process 7.0에 대한 새로운 RUP 인증 시험이 출시되었습니다. 이 시험은 IBM Rational Certified Specialist - Rational Unified [6]Process라는 이전 버전의 과정을 대체합니다.새로운 검사에서는 RUP 콘텐츠뿐만 아니라 프로세스 구조 [7]요소와 관련된 지식도 테스트됩니다.

새로운 RUP 인증 시험에 합격하려면 IBM의 Test 839: Rational Unified Process v7.0에 응시해야 합니다.52문제 시험을 칠 수 있는 75분의 시간이 주어집니다.합격점수는 62%[8]입니다.

6가지 베스트 프랙티스

소프트웨어 프로젝트에는 장애를 최소화하고 생산성을 높이기 위한 6가지 베스트 소프트웨어 엔지니어링 프랙티스가 정의되어 있습니다.다음과 같습니다.[9][10]

반복적으로 개발하다
모든 요건을 사전에 파악하는 것이 가장 좋지만, 그렇지 않은 경우가 많습니다.개발 단계의 비용을 최소화하기 위한 솔루션 제공을 다루는 몇 가지 소프트웨어 개발 프로세스가 있습니다.
요건 관리
사용자가 설정한 요건을 항상 염두에 두십시오.
컴포넌트 사용
고급 프로젝트를 해체하는 것이 제안될 뿐만 아니라 사실상 불가피한 상황이다.따라서 개별 컴포넌트가 대규모 시스템에 통합되기 전에 테스트할 수 있습니다.또한 코드 재사용은 큰 이점이며 객체 지향 프로그래밍을 사용하여 보다 쉽게 수행할 수 있습니다.
시각적으로 모델링
다이어그램을 사용하여 모든 주요 구성 요소, 사용자 및 이들의 상호 작용을 나타냅니다.Unified Modeling Language의 줄임말인 "UML"은 이 작업을 보다 실현하기 위해 사용할 수 있는 도구 중 하나입니다.
품질 확인
테스트는 항상 프로젝트의 주요 부분으로 삼아야 합니다.프로젝트가 진행됨에 따라 테스트는 더욱 어려워지지만 소프트웨어 제품 작성에는 항상 중요한 요소가 될 것입니다.
변경 제어
많은 프로젝트가 여러 팀에 의해 작성되며, 때로는 다양한 장소에서 다양한 플랫폼을 사용할 수 있습니다.따라서 시스템에 대한 변경사항이 항상 동기화 및 확인되도록 하는 것이 중요합니다(계속적인 통합 참조).

「 」를 참조해 주세요.

레퍼런스

  1. ^ IBM, Rational 인수
  2. ^ Jacobson, Sten (2002-07-19). "The Rational Objectory Process - A UML-based Software Engineering Process". Rational Software Scandinavia AB. Archived from the original on 2019-05-27. Retrieved 2014-12-17.
  3. ^ Kruchten, Philippe (2004-05-01). The Rational Unified Process: An Introduction. Addison-Wesley. p. 33. ISBN 9780321197702. Retrieved 2014-12-17.
  4. ^ Aked, Mark (2003-11-25). "RUP in brief". IBM. Retrieved 2011-07-12.
  5. ^ "Archived copy". Archived from the original on 2014-01-06. Retrieved 2013-08-03.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  6. ^ Krebs, Jochen (2007-01-15). "The value of RUP certification". IBM. Retrieved 2014-05-05.
  7. ^ "Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0". IBM. Retrieved 2008-05-13.
  8. ^ "Test 839: Rational Unified Process v7.0". IBM. Retrieved 2008-05-13.[영구 데드링크]
  9. ^ Stephen Schach (2004).클래식 및 객체 지향 소프트웨어 엔지니어링6/e, WCB McGraw Hill, New York, 2004.
  10. ^ Rational Unified Process 백서 2009-05-01년 Wayback Machine에 아카이브

추가 정보

  • 이바 제이콥슨, 그래디 부치, 제임스 럼보(1999년).통합 소프트웨어 개발 프로세스
  • 게리 폴리스, 리즈 어거스틴, 크리스 로, 재스 매드허(2003).소규모 팀을 위한 소프트웨어 개발: RUP 중심의 접근법
  • 크롤에 따르면 Philippe Kruchten (2003).간편한 통합 프로세스, The: RUP 실무자 가이드
  • 크롤에 의하면, Bruce Mac Isaac(2006).민첩성 및 규율 간소화: OpenUP 및 RUP에서 제공하는 작업 방식
  • Philippe Kruchten(1998).합리적인 통합 프로세스: 개요
  • Ahmad Shuja, Jochen Krebs(2007).RUP 레퍼런스 및 인증 가이드
  • Walker Royce, 소프트웨어 프로젝트 관리, 통합 프레임워크

외부 링크