통합 프로세스
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
통합 프로세스는 반복적이고 점진적인 개발을 통해 소프트웨어 시스템을 구축하는 프레임워크이다. 이 프로세스는 아키텍처 중심, 위험 중심, 유스 케이스 기반의 특징을 가지며, 착수, 정련, 구축, 전이의 4단계로 구성된다. 각 단계는 여러 번의 반복으로 이루어지며, 프로젝트의 규모와 특성에 따라 반복 횟수가 달라진다. 통합 프로세스는 프로젝트 초기에 위험을 해결하고, 유스 케이스를 통해 시스템 기능을 정의하며, 다양한 모델링 도구를 활용한다. 또한, 래셔널 통합 프로세스(RUP)를 비롯하여 다양한 개선 및 변형이 존재하며, 조직은 자체적으로 프로세스를 수정하고 확장하여 사용한다.
더 읽어볼만한 페이지
- 소프트웨어 개발 프로세스 - 버전 관리
버전 관리는 파일 변경 이력을 체계적으로 관리하는 시스템이며, 다양한 구조와 소스 관리 모델을 통해 협업을 지원하고, 비즈니스 등 다양한 분야에서 활용된다. - 소프트웨어 개발 프로세스 - 소프트웨어 개발 수명 주기
소프트웨어 개발 수명 주기(SDLC)는 시스템 설계자와 개발자가 따르는 일련의 단계로, 예비 분석부터 폐기까지 여러 단계를 거치며, 폭포수 모델, 시스템 분석 및 설계(SAD), 객체 지향 분석 및 설계(OOAD) 등 다양한 방법론을 포함한다.
| 통합 프로세스 | |
|---|---|
| 개요 | |
| 이름 | 래셔널 통일 프로세스 (Rational Unified Process, RUP) |
| 종류 | 소프트웨어 개발 방법론 |
| 개발 주체 | 래셔널 소프트웨어 (Rational Software, 현 IBM) |
| 기반 | 객체 지향 소프트웨어 개발 |
| 특징 | |
| 특징 | 반복적 개발 프로세스 사용 사례 중심 아키텍처 중심 위험 관리 |
| 핵심 요소 | |
| 역할 (Roles) | 누가 무엇을 하는가? |
| 활동 (Activities) | 어떻게 역할을 수행하는가? |
| 산출물 (Artifacts) | 활동의 결과물은 무엇인가? |
| 워크플로우 (Workflows) | 활동의 순서는 어떻게 되는가? |
| 6가지 모범 사례 | |
| 모범 사례 | 반복적인 개발 요구 사항 관리 컴포넌트 기반 아키텍처 사용 시각적 모델링 지속적인 품질 검증 변경 관리 |
| 단계 | |
| 착수 (Inception) | 프로젝트의 타당성 조사 및 범위 정의 |
| 구체화 (Elaboration) | 핵심 아키텍처 설계 및 위험 요소 식별 |
| 구축 (Construction) | 시스템 개발 및 통합 |
| 전환 (Transition) | 시스템 배포 및 사용자 교육 |
| 관련 정보 | |
| 관련 | 오픈 통합 프로세스 (OpenUP) IBM 래셔널 방법 프레임워크 (IBM Rational Method Framework, RMF) |
2. 통합 프로세스의 특징
통합 프로세스는 특정 조직이나 프로젝트에 맞게 조정해야 하는 확장 가능한 프레임워크이다. '래셔널 통합 프로세스(RUP)' 역시 사용자 정의가 가능한 프레임워크이므로, 프로세스 개선이 통합 프로세스(UP)에서 비롯된 것인지, RUP에서 비롯된 것인지 구분하기 어려워 두 이름은 혼용되는 경향이 있다.
'래셔널 통합 프로세스'와 구별되는 '통합 프로세스'라는 이름은 일반적인 프로세스를 설명하는 데 사용되며, IBM의 상표권 침해 문제를 피하기 위해 사용되기도 한다. 이 프로세스를 처음 설명한 책은 1999년 Ivar Jacobson, Grady Booch, James Rumbaugh가 출판한 ''The Unified Software Development Process''이다. 이후 Rational Software와 관련 없는 저자들은 'Unified Process'라는 이름을, Rational Software 관련 저자들은 'Rational Unified Process'라는 이름을 사용했다.
2012년에는 통합 프로세스, 스크럼, 익스트림 프로그래밍 등의 방법론을 채택하고 확장한 하이브리드 프레임워크인 디시플린드 애자일 딜리버리 프레임워크가 출시되었다.
2. 1. 반복적이고 점진적인 개발
통합 프로세스는 반복적이고 점진적인 개발 프로세스이다. 상세, 구축 및 전환 단계는 일련의 시간 제한 반복으로 나뉜다. (시작 단계는 대규모 프로젝트의 경우 반복으로 나눌 수도 있다.) 각 반복의 결과는 이전 릴리스에 비해 기능이 추가되거나 개선된 시스템 릴리스인 ''증분''을 생성한다.
대부분의 반복에서 대부분의 프로세스 분야(요구 사항, 설계, 구현, 테스트)에 대한 작업이 포함되지만, 상대적인 노력과 강조점은 프로젝트 진행 과정에 따라 변경된다.
2. 2. 아키텍처 중심
통합 프로세스는 아키텍처가 시스템 구축을 위한 프로젝트 팀 노력의 핵심이라고 주장한다. 단일 모델로는 시스템의 모든 측면을 포괄할 수 없으므로, 통합 프로세스는 여러 아키텍처 모델과 뷰를 지원한다.통합 프로세스의 가장 중요한 결과물 중 하나는 정교화 단계에서 생성되는 실행 가능한 아키텍처 기반선이다. 이 시스템의 부분적인 구현은 아키텍처를 검증하고 나머지 개발의 기반 역할을 한다.
2. 3. 위험 중심
통합 프로세스는 프로젝트 팀이 프로젝트 수명 주기 초기에 가장 중요한 위험을 해결하는 데 집중하도록 요구한다. 각 반복, 특히 정교화 단계의 결과물은 가장 큰 위험이 먼저 해결되도록 선택해야 한다.2. 4. 유스 케이스 기반
유스 케이스는 시스템 기능을 정의하는 주요 모델링 도구이다. 또한 기술적인 팀 구성원과 비기술적인 팀 구성원 간의 직접적인 의사 소통 수단으로 작용한다.3. 프로젝트 생명주기 (통합 프로세스의 단계)
통합 프로세스는 프로젝트를 착수, 정련, 구축, 전이의 4단계로 나누며, 각 단계는 일반적으로 여러 번 반복된다. 실제 반복 횟수는 프로젝트 규모와 특성에 따라 달라지는데, 이는 특정 프로젝트 예시일 뿐이다.
- 착수: 시스템에 대한 대략적인 비전과 사업 타당성을 만들고, 범위를 정의하며, 대략적인 비용 및 프로젝트 일정을 추정한다.
- 정련: 시스템 아키텍처 구축 및 검증을 목표로 한다. 유스 케이스 다이어그램, 개념 다이어그램, 패키지 다이어그램 등이 이 단계에서 생성된다.
- 구축: 정련 단계에서 마련된 토대 위에 시스템의 나머지 부분을 구축하며, 시스템 기능은 일련의 짧고 시간 제한적인 반복을 통해 구현된다.
- 전이: 시스템을 목표 사용자에게 배포하고, 초기 릴리스 피드백을 통해 개선 사항을 통합한다.
3. 1. 착수 단계
착수 단계는 프로젝트에서 가장 짧은 단계이며, 이상적으로는 매우 짧아야 한다. 착수 단계가 길어진다면 이는 과도한 사전 명세의 징후일 수 있으며, 이는 통합 프로세스의 정신에 어긋난다.이 단계에서는 시스템에 대한 대략적인 비전을 개발하고, 사업 타당성을 만들고, 범위를 정의하며, 대략적인 비용 추정 및 프로젝트 일정을 작성한다.
3. 2. 정련 단계
정련 단계에서 프로젝트 팀은 시스템 요구 사항의 상당 부분을 파악해야 한다. 그러나 정련의 주요 목표는 알려진 위험 요소를 해결하고 시스템 아키텍처를 구축하고 검증하는 것이다. 이 단계에서 일반적으로 수행되는 프로세스에는 유스 케이스 다이어그램, 개념 다이어그램(기본 표기법만 있는 클래스 다이어그램), 패키지 다이어그램(아키텍처 다이어그램)의 생성이 포함된다.아키텍처는 주로 실행 가능한 아키텍처 베이스라인을 구현하여 검증한다. 이는 시스템의 부분적인 구현으로, 가장 아키텍처적으로 중요한 핵심 구성 요소를 포함한다. 실행 가능한 아키텍처 베이스라인은 일련의 작은 시간 제한 반복으로 구축된다. 정련 단계가 끝나면 시스템 아키텍처가 안정화되어야 하며, 실행 가능한 아키텍처 베이스라인은 아키텍처가 성능, 확장성 및 비용 측면에서 주요 시스템 기능을 지원하고 올바른 동작을 나타낼 것임을 입증해야 한다.
최종 정련 단계의 결과물은 구축 단계에 대한 계획(비용 및 일정 추정 포함)이다. 이 계획은 정련 단계의 경험을 바탕으로 해야 하며, 정련 단계에서 중요한 위험 요소가 해결되었으므로 정확하고 신뢰할 수 있어야 한다.
3. 3. 구축 단계
구축은 프로젝트의 가장 큰 단계이다. 이 단계에서 시스템의 나머지 부분은 정교화 단계에서 마련된 토대 위에 구축된다. 시스템 기능은 일련의 짧고 시간 제한적인 반복을 통해 구현된다. 각 반복의 결과는 실행 가능한 소프트웨어 릴리스로 이어진다. 구축 단계에서 전체 텍스트 유스 케이스를 작성하는 것이 일반적이며, 각 유스 케이스는 새로운 반복의 시작점이 된다. 이 단계에서 사용되는 일반적인 UML 다이어그램에는 활동 다이어그램, 시퀀스 다이어그램, 협동 다이어그램, 상태 전이 다이어그램, 상호작용 개요 다이어그램이 있다. 위험이 낮고 구현이 쉬운 요소에 대한 반복적인 구현이 이루어진다. 최종 구축 단계의 결과물은 전환 단계에서 배포할 준비가 된 소프트웨어이다.3. 4. 전이 단계
전이 단계는 프로젝트의 마지막 단계이다. 이 단계에서는 시스템이 목표 사용자에게 배포된다. 초기 릴리스에서 받은 피드백은 여러 번의 전이 단계를 거치면서 추가 개선 사항을 통합하는 결과로 이어질 수 있다. 전이 단계에는 시스템 변환 및 사용자 교육도 포함된다.4. 통합 프로세스의 개선 및 변형
통합 프로세스는 특정 조직이나 프로젝트에 맞게 수정해야 하는 확장 가능한 프레임워크이다. 래셔널 통합 프로세스(RUP) 역시 사용자 정의가 가능한 프레임워크이기 때문에, 통합 프로세스(UP)와 RUP는 서로 바꿔서 사용되는 경향이 있다.
IBM의 상표인 "래셔널 통합 프로세스"와 "RUP"와는 달리, "통합 프로세스"라는 이름은 일반적인 프로세스를 설명하거나 상표권 문제를 피하기 위해 사용된다. 1999년 Ivar Jacobson, Grady Booch, James Rumbaugh가 출판한 ''The Unified Software Development Process''가 이 프로세스를 설명한 최초의 책이다. 이후 Rational Software와 관련 없는 저자들은 "Unified Process"라는 이름을, Rational Software 관련 저자들은 "Rational Unified Process"라는 이름을 사용했다.
2012년에는 통합 프로세스, 스크럼, 익스트림 프로그래밍 등의 전략을 채택한 하이브리드 프레임워크인 디시플린드 애자일 딜리버리 프레임워크가 출시되었다.
통합 프로세스의 개선 사항은 프로젝트 ''분야'' 또는 ''워크플로''를 분류하는 방식에 따라 달라진다. 래셔널 통합 프로세스는 9가지 분야를 정의하고, 엔터프라이즈 통합 프로세스는 RUP를 확장하여 8개의 "엔터프라이즈" 분야를 추가한다. OpenUP/Basic 및 애자일 통합 프로세스와 같은 애자일 개선 사항은 분야 수를 줄여 RUP를 단순화한다.
개선 사항은 프로젝트 아티팩트에 대한 강조점과 전환 단계 이후의 과정에서도 차이를 보인다. 래셔널 통합 프로세스에서 전환 단계는 보통 새로운 시작 단계로 이어지지만, 엔터프라이즈 통합 프로세스에서는 프로덕션 단계로 이어진다.
통합 프로세스를 사용하는 조직들은 자체적인 수정 및 확장을 지속적으로 통합하기 때문에, 개선 및 변형의 수는 매우 많다. 다음은 잘 알려진 개선 및 변형 목록이다.
- 애자일 통합 프로세스(AUP): 스콧 W. 앰블러가 개발한 경량 변형
- 기본 통합 프로세스(BUP): IBM이 개발하고 OpenUP의 전신인 경량 변형
- 엔터프라이즈 통합 프로세스(EUP): 래셔널 통합 프로세스의 확장
- 에센셜 통합 프로세스(EssUP): 이바 야콥슨이 개발한 경량 변형
- 오픈 통합 프로세스(OpenUP): Eclipse Process Framework 소프트웨어 개발 프로세스
- 래셔널 통합 프로세스(RUP): IBM / 래셔널 소프트웨어 개발 프로세스
- 오라클 통합 방법론(OUM): 오라클 개발 및 구현 프로세스
- 래셔널 통합 프로세스-시스템 엔지니어링(RUP-SE): 시스템 엔지니어링을 위해 래셔널 소프트웨어가 맞춤화한 RUP 버전
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com