합리적인 통합 프로세스
Rational unified process시리즈의 일부: |
소프트웨어 개발 |
---|
RUP(Rational Unified Process)는 2003년부터 IBM의 부서인 [1]Rational Software Corporation에 의해 만들어진 반복적인 소프트웨어 개발 프로세스 프레임워크입니다. RUP는 단일한 구체적인 규정 프로세스가 아니라 적응 가능한 프로세스 프레임워크입니다.개발 조직 및 소프트웨어 프로젝트 팀이 요구에 적합한 프로세스 요소를 선택하도록 설계되었습니다.RUP는 통합 프로세스의 특정 구현입니다.
역사
Rational Software는 원래 합리적인 통합 프로세스를 소프트웨어 프로세스 제품으로 개발했습니다.이 제품에는 샘플 아티팩트와 다양한 유형의 활동에 대한 자세한 설명이 포함된 하이퍼링크된 지식 기반이 포함되어 있습니다.RUP는 프로세스를 사용자 정의할 수 있는 IBM RMC(Rational Method Composer) 제품에 포함되어 있습니다.
경험이 풍부한 Rational 기술 담당자인 Philippe Cruchten은 원래 RUP 팀을 이끄는 임무를 맡았습니다.
이러한 초기 버전은 객체 지향 시스템을 구축하는 Rational Software 조직의 광범위한 현장 경험(Rational 현장 직원에 의해 Rational 접근법이라고 칭함)과 사용 사례와 같은 관행에 대한 Objectory의 지침을 결합했습니다.모델링에 대한 Jim Rumbaugh의 객체 모델링 기술(OMT) 접근 방식, Grady Booch의 Booch 방법 및 새로 출시된 UML 0.[2][3]8의 광범위한 콘텐츠를 통합했습니다.
증가하는 이 지식 기반에 더욱 쉽게 접근할 수 있도록 돕기 위해 Philippe Kruchten은 현대 소프트웨어 엔지니어링을 위한 명시적인 프로세스 프레임워크의 조립을 담당했습니다.이러한 노력은 Objectory에서 개발한 HTML 기반 프로세스 전달 메커니즘을 사용했습니다.결과적으로 "합리적 통합 프로세스"(RUP)는 Rational을 위한 전략적 삼각대를 완성했습니다.
- 발전을 이끈 조정 가능한 과정
- 해당 프로세스의 적용을 자동화한 도구
- 프로세스와 툴의 채택을 가속화하는 서비스.
이 지침은 Rational이 인수한 기업의 경험을 바탕으로 지식을 갖춘 후속 버전에서 강화되었습니다.
1997년, 요건과 테스트 규율이 접근법에 추가되었으며, Requisite, Inc.의 Dean Leffingwell 등에 의해 개발된 Requirements College 방법과 SQA Inc.에서 개발된 SQA Process 방법에서 나온 많은 추가 자료가 Rational Software에 의해 인수되었습니다.
1998년에 Rational Software는 두 개의 새로운 분야를 추가했습니다.
- 비즈니스 모델링, 이 콘텐츠의 대부분은 이미 Objectory Process(객관적 프로세스)에 있었습니다.
- Pure Atria Corporation 인수를 통해 조달된 구성 및 변경 관리 분야.
이러한 추가 사항은 Rational이 정의하고 RUP 내에서 현대 소프트웨어 엔지니어링을 위한 6가지 모범 사례로 명시한 포괄적인 원칙 세트로 이어집니다.
- 리스크를 주요 반복[4] 동인으로 하여 반복적으로 개발
- 요구사항 관리
- 구성요소 기반 아키텍처 사용
- 소프트웨어를 시각적으로 모델링
- 품질을 지속적으로 검증
- 제어 변경사항
이러한 모범 사례는 Rational의 제품군과 긴밀하게 연계되어 있으며, 둘 다 Rational의 제품을 지속적으로 개발하는 데 도움이 될 뿐만 아니라 Rational의 현장 팀이 고객의 소프트웨어 개발 작업의 품질과 예측 가능성을 향상시키는 데 사용되었습니다.
성능 테스트, UI 디자인, 데이터 엔지니어링 및 UML 1.1의 변경 사항을 반영하는 업데이트를 포함한 추가 기술이 포함되었습니다.
1999년에는 UML 1.3을 반영하여 실시간 소프트웨어 개발 및 업데이트를 지원하는 기술과 함께 프로젝트 관리 규율이 도입되었습니다.게다가, 그 과정을 설명한 첫 번째 책인 통합 소프트웨어 개발 프로세스( ISBN0-201-57169-2)는 같은 해에 출판되었습니다.
2000년과 2003년 사이에, 많은 변화들이 RUP 인스턴스 제정 및 RUP 프레임워크의 사용자 정의를 위한 도구 지원 외에도 반복 개발을 통한 지속적인 Rational 현장 경험의 지침을 도입했습니다.이러한 변경 사항은 다음과 같습니다.
- eXtreme 프로그래밍(XP)과 같은 접근 방식의 개념과 기술 도입은 나중에 애자일 방법으로 통칭될 것입니다.여기에는 페어 프로그래밍, 테스트 우선 설계 및 대규모 프로젝트에서 사용할 수 있도록 XP를 확장하는 방법을 설명하는 문서와 같은 기술이 포함되었습니다.
- 다양한 반복 개발 맥락에서 시험 작업이 수행된 방식을 더 잘 반영하기 위해 시험 분야의 전면적인 개편.
- 다양한 도구에서 RUP 관행을 제정하기 위한 지원 지침("도구 멘토")의 도입.이들은 기본적으로 Rational 도구 사용자에게 단계별 방법 지원을 제공했습니다.
- 고객이 RUP 프로세스 프레임워크에서 부품을 선택하고, 자체 추가 기능을 사용하여 선택 항목을 사용자 지정할 수 있는 방식으로 RUP의 사용자 지정을 자동화하고, Rational의 후속 릴리스의 개선 사항을 통합할 수 있습니다.
IBM은 2003년 2월에 Rational Software를 인수했습니다.
2006년에 IBM은 Agile 프로젝트의 제공을 위해 맞춤화된 RUP의 하위 집합을 만들었습니다 - Open이라는 OpenSource 방법으로 출시되었습니다.이클립스 [5]웹사이트를 통해 UP.
합리적인 통합 프로세스 주제
RUP 구성요소
RUP는 일련의 구성요소 및 컨텐츠 요소를 기반으로 제작할 내용, 필요한 기술 및 구체적인 개발 목표를 달성하는 방법을 설명하는 단계별 설명을 제공합니다.주요 구성 요소 또는 내용 요소는 다음과 같습니다.
- 역할(누구) – 역할은 일련의 관련 기술, 역량 및 책임을 정의합니다.
- 작업 생산물(무엇) – 작업 생산물은 작업 과정에서 생성된 모든 문서와 모델을 포함하여 작업의 결과를 나타냅니다.
- 작업(방법) – 의미 있는 결과를 제공하는 역할에 할당된 작업 단위를 설명하는 작업입니다.
각 반복 내에서 작업은 9개의 분야로 분류됩니다.
- 6가지 "공학 분야"
- 비즈니스 모델링
- 요구 사항들
- 분석 및 설계
- 실행
- 시험
- 배포
- 세 가지 지원 분야
4개의 프로젝트 수명 주기 단계
RUP는 4단계로 구성된 프로젝트 수명 주기를 결정했습니다.이러한 단계를 통해 프로세스를 '물벼락' 스타일의 프로젝트를 제시하는 방법과 유사한 방식으로 높은 수준에서 제시할 수 있습니다. 그러나 본질적으로 프로세스의 핵심은 모든 단계 내에 있는 개발의 반복에 있습니다.또한 각 단계의 마지막에는 달성되는 목표를 나타내는 하나의 주요 목표와 이정표가 있습니다.시간 경과에 따른 RUP 단계 및 분야의 시각화를 RUP 혹 차트라고 합니다.
개시 단계
첫 번째 목표는 초기 비용 및 예산을 검증하기 위한 기준으로 시스템 범위를 적절하게 조정하는 것입니다.이 단계에서는 비즈니스 상황, 성공 요인(예상 수익, 시장 인지도 등), 재무 예측을 포함하는 비즈니스 사례를 수립합니다.비즈니스 사례를 보완하기 위해 기본 활용 사례 모델, 프로젝트 계획, 초기 위험 평가 및 프로젝트 설명(핵심 프로젝트 요구 사항, 제약 조건 및 주요 기능)을 생성합니다.이러한 작업이 완료되면 다음 기준에 따라 프로젝트를 확인합니다.
- 범위 정의 및 비용/일정 추정치에 대한 이해관계자의 동의.
- 1차 사용 사례의 충실도로 입증된 요구사항 이해.
- 비용/일정 추정치, 우선순위, 리스크 및 개발 프로세스에 대한 신뢰성.
- 개발된 모든 건축 프로토타입의 깊이와 폭.
- 실제 지출과 계획된 지출을 비교하는 기준을 설정합니다.
프로젝트가 수명 주기 목표 마일스톤이라고 하는 이 마일스톤을 통과하지 못하면 취소하거나 기준을 더 잘 충족하도록 재설계한 후 반복할 수 있습니다.
정교화 단계
주요 목표는 이 단계가 끝날 때까지 분석을 통해 식별된 주요 위험 항목을 완화하는 것입니다.구체화 단계는 프로젝트가 구체화되기 시작하는 단계입니다.이 단계에서는 문제 영역 분석이 수행되고 프로젝트의 아키텍처가 기본 형태를 얻습니다.
구체화 단계의 결과는 다음과 같습니다.
- 사용 사례와 행위자가 식별되고 대부분의 사용 사례 설명이 개발된 사용 사례 모델.사용 사례 모델은 80% 완성도가 있어야 합니다.
- 소프트웨어 시스템 개발 프로세스의 소프트웨어 아키텍처에 대한 설명입니다.
- 아키텍처적으로 중요한 사용 사례를 실현하는 실행 가능한 아키텍처입니다.
- 개정된 비즈니스 사례 및 위험 목록.
- 전체 프로젝트에 대한 개발 계획입니다.
- 확인된 각 기술 위험을 입증 가능하게 완화하는 프로토타입.
- 예비 사용자 설명서(선택 사항)
이 단계에서는 다음과 같은 질문에 답하는 라이프사이클 아키텍처 이정표 기준을 통과해야 합니다.
- 제품의 비전은 안정적입니까?
- 그 건축물은 안정적입니까?
- 실행 가능한 데모는 주요 위험 요소가 해결되고 해결되었음을 나타냅니까?
- 시공단계 계획이 충분히 상세하고 정확합니까?
- 모든 이해관계자는 현재 아키텍처의 맥락에서 현재 계획을 사용하여 현재 비전을 달성할 수 있다는 데 동의합니까?
- 실제 리소스 지출과 계획된 리소스 지출을 수용할 수 있습니까?
프로젝트가 이 마일스톤을 통과할 수 없는 경우 취소하거나 재설계할 시간이 있습니다.그러나 이 단계를 종료한 후, 프로젝트는 변경이 훨씬 어렵고 유해한 위험이 높은 작업으로 전환됩니다.
정교화를 위한 핵심 도메인 분석은 시스템 아키텍처입니다.
시공단계
주요 목표는 소프트웨어 시스템을 구축하는 것입니다.이 단계에서는 시스템의 구성 요소 및 기타 기능 개발에 중점을 둡니다.이 단계는 코딩의 대부분이 발생하는 단계입니다.대규모 프로젝트에서는 사용 사례를 관리 가능한 세그먼트로 분할하여 입증 가능한 프로토타입을 생산하기 위한 노력으로 여러 개의 건설 반복 작업을 개발할 수 있습니다.
전환 단계
주요 목표는 시스템을 개발에서 생산으로 '전환'하여 최종 사용자가 시스템을 사용하고 이해할 수 있도록 하는 것입니다.이 단계의 활동에는 최종 사용자와 유지 관리자를 교육하고 베타 테스트를 통해 최종 사용자의 기대와 대조적으로 시스템을 검증하는 것이 포함됩니다.또한 시스템은 평가 단계를 거치며, 필요한 작업을 수행하지 않는 개발자는 교체 또는 제거됩니다.또한 제품은 Inception 단계에서 설정된 품질 수준과 비교하여 확인됩니다.
모든 목표가 충족되면 제품 릴리스 마일스톤에 도달하고 개발 주기가 종료됩니다.
IBM Rational Method Composer 제품
IBM Rational Method Composer 제품은 프로세스를 작성, 구성, 보기 및 게시하기 위한 도구입니다.자세한 내용은 IBM Rational Method Composer 및 EPF(오픈 소스 버전 Eclipse 프로세스 프레임워크) 프로젝트를 참조하십시오.
인증
2007년 1월 IBM Certified Solution Designer - Rational Unified Process 7.0에 대한 새로운 RUP 인증 시험이 발표되었습니다. 이 시험은 IBM Rational Certified Specialist - Rational Unified [6]Process라는 이전 버전의 과정을 대체합니다.새로운 검사는 RUP 내용뿐만 아니라 프로세스 구조 [7]요소와 관련된 지식도 테스트합니다.
새로운 RUP 인증 시험에 합격하려면 IBM의 테스트 839: Rational Unified Process v7.0을 응시해야 합니다.52번 문제 시험을 칠 수 있는 75분의 시간이 주어집니다.합격 점수는 62%[8]입니다.
6가지 모범 사례
소프트웨어 프로젝트를 위해 결함을 최소화하고 생산성을 높이기 위한 6가지 모범 소프트웨어 엔지니어링 관행이 정의되어 있습니다.다음은 다음과 같습니다.[9][10]
- 반복 개발
- 모든 요구 사항을 미리 알고 있는 것이 가장 좋습니다. 하지만 그렇지 않은 경우가 많습니다.개발 단계 측면에서 비용을 최소화하기 위한 솔루션 제공을 다루는 여러 소프트웨어 개발 프로세스가 존재합니다.
- 요구사항 관리
- 사용자가 설정한 요구 사항을 항상 염두에 두십시오.
- 구성요소 사용
- 선진 프로젝트를 해체하는 것은 제안될 뿐만 아니라 실제로 피할 수 없는 일입니다.따라서 개별 구성 요소가 더 큰 시스템에 통합되기 전에 해당 구성 요소를 테스트할 수 있습니다.또한 코드 재사용은 큰 장점이며 객체 지향 프로그래밍을 사용하여 더 쉽게 수행할 수 있습니다.
- 시각적 모델링
- 다이어그램을 사용하여 모든 주요 구성요소, 사용자 및 이들의 상호작용을 참조하십시오.통합 모델링 언어의 줄임말인 "UML"은 이 작업을 보다 실현 가능하게 하는 데 사용할 수 있는 도구 중 하나입니다.
- 품질 확인
- 항상 테스트를 프로젝트의 주요 부분으로 지정합니다.테스트는 프로젝트가 진행됨에 따라 더 무거워지지만 소프트웨어 제품을 만드는 데 있어 지속적인 요소가 되어야 합니다.
- 제어 변경사항
- 많은 프로젝트가 많은 팀에 의해 만들어지고, 때로는 다양한 위치에서, 다양한 플랫폼이 사용될 수 있습니다.따라서 시스템에 대한 변경 사항을 지속적으로 동기화하고 확인해야 합니다(연속 통합 참조).
참고 항목
- 매크로스코프(방법론 제품군)
- 신속한 변화를 위한 모델링(AM)
- 신속한 변화를 위한 통합 프로세스(AUP)
- 규정된 민첩한 제공(DAD)
- 동적 시스템 개발 방법(DSDM)
- 컴퓨터 프로그래밍
- 기능 중심 개발(FDD)
- 프로젝트 수명 주기
- 품질관리 및 품질보증
- 확장된 신속한 변화를 위한 프레임워크 - 익스트림 프로그래밍(XP)과 같은 신속한 변화를 위한 소프트웨어 개발 방법을 통합하는 RUP의 하위 제품
- 소프트웨어 아키텍처
- 소프트웨어 구성 요소
- 소프트웨어 개발 프로세스
- 소프트웨어 공학
- 소프트웨어 테스트
- 테스트 기반 개발(TDD)
레퍼런스
- ^ IBM, Rational 인수
- ^ 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.
- ^ Kruchten, Philippe (2004-05-01). The Rational Unified Process: An Introduction. Addison-Wesley. p. 33. ISBN 9780321197702. Retrieved 2014-12-17.
- ^ Aked, Mark (2003-11-25). "RUP in brief". IBM. Retrieved 2011-07-12.
- ^ "OpenUP". Archived from the original on 2014-01-06. Retrieved 2013-08-03.
- ^ Krebs, Jochen (2007-01-15). "The value of RUP certification". IBM. Retrieved 2014-05-05.
- ^ "Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0". IBM. Retrieved 2008-05-13.
- ^ "Test 839: Rational Unified Process v7.0". IBM. Retrieved 2008-05-13.[영구 데드링크]
- ^ Stephen Schach (2004).고전적이고 객체 지향적인 소프트웨어 엔지니어링.6/e, WCB McGraw Hill, 뉴욕, 2004.
- ^ Wayback Machine에서 Rational Unified Process 백서 2009-05-01 보관
진일보한 내용
- 아이바 제이콥슨, 그래디 부치, 제임스 럼보 (1999).통합 소프트웨어 개발 프로세스
- Gary Pollice, Liz Augustine, Chris Lowe, Jas Madhur (2003).소규모 팀을 위한 소프트웨어 개발: ARUP 중심 접근법
- Per Kroll, Philippe Kruchten (2003).합리적인 유니파이드 프로세스로 간소화된 A: RUP에 대한 실무자
- Per Kroll, Bruce Mac Isaac (2006).민첩성 및 규율 향상: OpenUP 및 RUP의 실천
- Philippe Cruchten (1998).합리적인 통합 프로세스: 소개
- 아흐마드 슈자, 요헨 크렙스(2007).RUP 참조 및 인증 가이드
- Walker Royce, 소프트웨어 프로젝트 관리, 통합 프레임워크
- Paul Symkowiak, Philippe Kruchten (2003).테스트: RUP 철학
외부 링크
- ^ Szymkowiak, Paul; Kruchten, Philippe (February 2003). "Testing: The RUP Philosophy". Academia.Edu. Rational Software (Rational Edge e-zine). p. 11. Retrieved 2022-10-13.