개념:
|
백서: |
RUP(Rational Unified Process)는 Rational Software가 몇 년에 걸쳐 정제한 프로세스 프레임워크이며 모든 유형의 소프트웨어 프로젝트(소형부터 대형까지)에 광범위하게 사용됩니다. 최근 들어, 증가되고 있는 "기민한" 프로세스(예: XP(eXtreme Programming), SCRUM, FDD(Feature-Driven Development) 및 Crystal Clear Methodology)는 소형 시스템 빌드에 효과적인 방법으로 인식되고 있습니다. (Agile Alliance에 대한 자세한 정보는 www.agilealliance.org를 참조하십시오.)
다음 섹션은 프로젝트 팀이 RUP에서 정의된 보다 완전한 소프트웨어 개발 프로세스를 통해 기민한 프랙티스를 처리하는 방법을 알아보기 위한 여러 가지 방법 중 하나인 "기민한" 프랙티스의 일부를 평가하는 데 도움을 주기 위한 것입니다.
기민한 커뮤니티는 특히 작고 공존하는 프로젝트 팀에 적용할 수 있는 여러 "베스트 프랙티스"를 종합한 것입니다. RUP가 모든 규모의 프로젝트 팀을 대상으로 하지만, 소형 프로젝트에 성공적으로 적용될 수 있습니다. 일반적으로, RUP 및 기민한 커뮤니티 프로세스는 양질의 소프트웨어를 개발하는 데 필요한 주요 베스트 프랙티스(예: 반복적 개발 적용 및 일반 사용자에 중점적인)에 대해 유사한 관점을 가집니다.
다음 섹션은 기민한 커뮤니티에서 식별된 "베스트 프랙티스" 중 일부를
이러한 베스트 프랙티스에서 이익을 얻으려는 RUP 기반 프로젝트에 적용하는 방법에 대해 설명합니다. 이 경우, XP(eXtreme Programming) 방법론으로 표시되는 프랙티스에 특히 중점을 둡니다. (XP에 대한 자세한 정보는 http://www.extremeprogramming.org
웹 사이트를 참조하십시오.)
XP는 4가지 기본 "활동"(코딩, 테스트, 청취 및 설계)을 포함하며 실제로 RUP 규칙과 보다 밀접하게 결합되어 있습니다. 이러한 XP 활동은 추가 활동을 수행해야 하는 프랙티스 세트를 사용하여 수행되며 RUP의 다른 규칙 중 일부에 맵핑됩니다. XP의 프랙티스는 설명된 Extreme Programming에 따르면 다음과 같습니다.
예를 들어, "계획 게임" 프랙티스의 결과로 수행되는 활동은 주로 RUP의 프로젝트 관리 규칙에 맵핑됩니다. 그러나 비즈니스 모델링 및 릴리즈된 소프트웨어의 전개와 같은 일부 RUP 주제는 XP의 범위를 벗어납니다. 고객이 요구사항을 정의하고 제공해야 하므로 요구사항 도출은 XP의 범위를 크게 벗어납니다. 또한 XP는 보다 단순한 개발 프로젝트를 처리하기 때문에 RUP가 형상 및 변경 관리 규칙과 환경 규칙에서 자세히 다루는 문제를 매우 가볍게 처리할 수 있습니다.
XP와 RUP가 서로 겹치는 규칙의 경우, XP에 설명된 다음 규칙이 RUP에 적용될 수 있습니다(일부 경우에는 이미 적용됨).
올바른 프로세스가 "마이크로" 레벨에서 실행되어야 한다는 제안은 종종 성향에 맞지 않고 일부 회사 문화에 맞지 않을 수 있습니다. 따라서 RUP는 엄격한 시행을 지지하지 않습니다. 그러나 일부 상황에서 XP가 지지하는 프랙티스를 기반으로 하여 페어를 이루어 작업하는 것(그리고 일부 다른 팀 구성원과 함께 작업하는 것)은 예를 들어 다음과 같은 경우에 각 팀 구성원이 다른 구성원을 도울 수 있으므로 분명히 장점을 가지고 있습니다.
다음 XP 프랙티스는 대형 시스템에서 올바로 크기 조정되지 않으므로(XP가 그렇다고 주장하지도 않음) RUP에서 다음 조건에 따라 XP 프랙티스를 사용합니다.
최종적으로, 첫눈에 RUP(단순 설계)에서 잠재적으로 사용 가능하다고 여겨지는
XP 프랙티스는 일반적으로 적용될 때 약간의 면밀성과 주의가 필요합니다.
RUP가 "비기능적" 요구사항을 호출할 때 사용하는 방법을 처리할 때 로컬 최적화 문제점과 유사한 문제점이 있습니다. 이러한 요구사항은 또한 고객에게 비즈니스 가치를 전달하지만 내용으로 표시하기에는 다소 어렵습니다. XP가 제한조건이라고 하는 것 중 일부는 이 카테고리로 분류됩니다. RUP는 모든 종류의 추론적인 방법에 필요한 것 이상으로 설계하는 방법은 지지하지 않지만 구조적 모델(비기능적 요구사항을 충족하기 위한 핵심 중 하나인 모델)을 염두에 두고 설계하는 방법을 지지합니다.
따라서 RUP는 "단순 설계"가 모든 테스트 실행을 포함해야 한다는 것을 XP와 동의하지만, 여기에는 소프트웨어가 비기능적 요구사항을 충족시키는 것을 예시하는 테스트를 포함한다는 추가사항이 포함됩니다. 다시 말해, 이 점은 시스템 크기와 복잡도가 증가할 때나 구조가 전에 없던 구조이거나 비기능적 요구사항이 부담이 될 때 주요한 문제로 대두됩니다. 예를 들어, 데이터 정렬에 대한 요구(이기종 분산 환경에서 조작하기 위해)가 코드를 몹시 복잡하게 하는 것처럼 보이지만 이 요구는 프로그램 전체에서 여전히 필요합니다.
소형 프로젝트에 맞게 RUP를 조정하고 그에 따라
결과물 요구사항을 줄이면
XP 프로젝트의 동일 결과물과 이것을 어떻게 비교합니까? RUP의 소형 프로젝트에 대한
예제 개발 케이스에서 더 적은 결과물을 생성하도록 구성된 샘플 RUP 형상을 볼 수 있습니다(표 1에 표시됨).
XP 결과물
|
RUP 결과물
( ![]() |
---|---|
내용 대화의 추가 문서 |
비전 용어집 유스 케이스 모델 |
제한조건 | 추가 스펙 |
승인 테스트 및 단위 테스트 테스트 데이터 및 테스트 결과 |
|
소프트웨어(코드) | 구현 모델 |
릴리스 | ![]() ![]() |
메타포 | 소프트웨어 구조 문서 |
설계(CRC, UML 초안) 기술 타스크 및 기타 타스크 마지막에 생성되는 설계 문서 지원 문서 |
설계 모델 |
코딩 표준 | ![]() |
작업공간 테스트 프레임워크 및 툴 |
![]() ![]() |
릴리즈 계획 반복 계획 내용 추정 및 타스크 추정 |
소프트웨어 개발 계획
반복 계획 |
전체 계획 및 예산 | 비즈니스 케이스 위험 목록 |
진행에 대한 보고서 타스크 작업에 대한 시간 레코드 메트릭 데이터(자원, 범위, 품질, 시간 포함) 결과 추적 회의에 대한 보고서 및 기록 |
상태 평가 반복 평가 검토 레코드 |
결함(및 연관된 데이터) | 변경 요청 |
코드 관리 툴 | 프로젝트 저장소 ![]() |
스파이크(솔루션) | |
XP 자체(권장사항 및 가이드) | |
[XP에 포함되지 않음] |
표 1: 소형 프로젝트에 대한 결과물의 XP에서 RUP로의 맵핑
XP 및 RUP에서 결과물의 세분성이 서로 다르긴 하지만, 일반적으로 소형 프로젝트(XP 유형이 부족함 없이 처리함)에 대한 RUP의 결과물은 XP 프로젝트의 결과물에 아주 잘 맵핑됩니다.
소형 프로젝트에 대한
예제 개발 케이스는 또한 XP에서는 다뤄지지 않지만 여러 프로젝트에 필요한
몇 가지 결과물도 포함한다는 점을 주의하십시오. 여기에는 데이터 모델 및
전개와 관련된 결과물(예:
일반 사용자 지원 자료)이
포함됩니다.
RUP는 활동을 역할에 의해 수행되는 작업으로 정의합니다. 활동은 입력물을 사용하고 변환하거나 또는 새로 작성되거나 변경된 출력 결과물을 생성합니다. RUP는 RUP 규칙에 따라 이들 활동을 계속해서 열거하고 카테고리화합니다. 이러한 규칙에는 비즈니스 모델링, 요구사항, 분석 및 설계, 전개 및 프로젝트 관리가 포함됩니다.
활동은 생산하고 소비하는 결과물을 통해 시간과 관련됩니다. 활동은 입력이 사용 가능할 때(적절한 상태일 때) 논리적으로 시작할 수 있습니다. 이는 결과물 상태가 허용할 경우 생산자-소비자 활동 쌍이 시간적으로 겹칠 수 있음을 의미합니다. 엄격히 순서화될 필요는 없습니다. 활동은 결과물이 생성되어야 하는 방법에 대해 강력한 가이드를 제공하기 위한 것으로 프로젝트 관리자를 도와 계획하는 데 사용될 수도 있습니다.
라이프사이클, 결과물 및 활동에 대해 설명한 대로 RUP를 통해 짜여진 것이 예측 가능한 스케줄 및 예산으로 빌드된 양질의 소프트웨어를 만들어내는 것으로 증명된 "베스트 프랙티스": 소프트웨어 엔지니어링 원칙입니다. RUP는 활동(및 관련 결과물)을 통해 이러한 베스트 프랙티스를 지원하고 구현합니다. 베스트 프랙티스는 RUP를 통해 실행되는 주제입니다. XP가 "프랙티스"의 개념도 사용하지만 보이는 대로 RUP의 베스트 프랙티스 개념과 정확하게 대응되지는 않습니다.
XP는 소프트웨어 개발 보기를 일부 지원 프랙티스에 따라 사용 가능해지고 구조화되는 4가지 기본 활동(코딩, 테스트, 청취 및 설계)을 가짐으로 눈에 띄게 단순한 모습으로 표시합니다(제 9 장 Extreme Programming Explained에서 설명). 실제로, 앞서 참고한 바와 같이 XP 활동은 RUP 활동보다는 RUP 규칙에 대한 범위에 더 근접하며, XP 프로젝트에서 발생하는 많은 활동(네 가지 기본 활동 외)은 해당 프랙티스의 완성과 적용으로부터 나옵니다.
따라서 RUP 활동과 동등한 XP 활동이 있지만 XP의 "활동"은 공식적으로 식별되거나 그와 같이 설명되지 않습니다. 예를 들어, 제 4 장 Extreme Programming Installed에서 "User Stories"를 보면 "카드에 쓰여진 내용으로 요구사항 정의" 표제가 있고 이 장 전체에는 프로세스 설명과 사용자 내용의 개념, 생성되는 방법 및 주체에 대한 가이드가 설명되어 있습니다. 그리고 계속해서 XP 서적의 여러 섹션(결과물 중심 및 활동 중심이 혼합된 표제로)을 통해 여러 레벨의 규정 및 세부사항으로 "생성된 것"과 "수행된 것"을 모두 설명합니다.
보기에 높은 레벨의 RUP 규정은 활동과 활동의 입력 및 결과물을 처리하는 방법에서 완전성 및 더 큰 형식성으로부터 결과됩니다. XP에 규정이 부족한 것은 아니지만 부족한 상태로 남으려 할 경우, 형식성 및 세부사항이 간단히 생략됩니다. 특수성이 부족한 것은 강점도 약점도 아니지만 XP에서 자세한 정보가 부족한 것을 단순성과 혼동해서는 안됩니다. 세부사항을 갖지 않는 것이 경험이 많은 개발자에게는 좋겠지만 대부분의 경우 추가 세부사항은 새로운 팀 구성원과 팀의 소프트웨어 개발 방법에 대해 여전히 초보적인 지식을 가지고 있는 팀 구성원에게 큰 도움을 줍니다.
결과물에서와 마찬가지로 활동에서는 달성하려고 노력하는 것에 계속 중점을 두는 것이 중요합니다. 맹목적으로
활동을 수행하는 것은 올바른 프랙티스가 아닙니다.
목표를 달성하기 위해 필요할 때 볼 수 있도록 활동 및 관련 가이드라인이 제공되지만
달성하려고 노력 중인 것을 해결하지 못한 데 대한 변명으로 사용되어서는 안됩니다. XP에는 이러한 원칙이 명료하게 표현되어 있으며 모든 RUP 사용자는 이를 적용해야 합니다.
RUP에서 활동은 역할(또는 보다 정확히 말하면 역할을 수행하는 개인 또는 그룹)에 의해 수행된다고 합니다. 또한 역할은 특정 결과물에 대한 책임을 가집니다. 책임을 맡은 역할은 일반적으로 결과물을 작성하고 다른 역할(적어도 허용된 경우)이 작성한 변경사항이 결과물을 중단시키지 않는지 확인합니다. 개인 또는 그룹은 하나의 역할 또는 여러 역할을 수행할 수 있습니다. 역할은 조직에서 하나의 위치 또는 "슬롯"에만 맵핑될 필요는 없습니다.
Extreme Programming Explained는 XP에 작용할 수 있는 7가지 역할(프로그래머, 고객, 테스터, 추적자, 지도원, 컨설턴트 및 총 책임자)을 식별하고 이 역할의 책임과 이를 수행하는 사람에게 필요한 능력에 대해 설명합니다. 이러한 역할에 대한 참조는 일부 기타 XP 서적에도 나와 있습니다. XP와 RUP의 역할 수에 차이가 있는 것은 설명하기 쉽습니다.
RUP 역할을 소형 프로젝트에 맵핑할 때 직위 또는 직함의 수가 다섯 개므로
RUP 역할이 대응되는 XP 유사 역할의 수가 상당히 감소됩니다.
표 3(RUP에서 그려짐)은 대응되는 XP 역할과의 맵핑을 표시합니다.
XP 역할 | 예제 RUP 소형 프로젝트 팀 구성원 | RUP 역할 |
---|---|---|
지도원 컨설턴트 총 책임자 |
Sally Slalom, 선임 관리자 | 프로젝트 관리자![]() 기술 검토자 형상 관리자 변경 제어 관리자 |
고객 | 스테이크홀더(비전에
문서화되어 있음) |
관리 검토자 기술 검토자(요구사항) |
고객 총 책임자 추적자 |
Tom Telemark, 선임 소프트웨어 엔지니어 | 시스템 분석가 요구사항 지정자 사용자 인터페이스 설계자 소프트웨어 아키텍트 기술 검토자 테스트 관리자 ![]() 및 더 작은 범위의 개발자 역할. |
프로그래머 테스터 |
Susan Snow, 소프트웨어 엔지니어 Henry Halfpipe, 하급 소프트웨어 엔지니어 |
설계자 구현자 기술 검토자 통합자 ![]() ![]() ![]() |
추적자 | Patrick Powder, 부관리자 | 프로젝트 웹 사이트를 유지보수하고 프로젝트 관리자 역할이 활동을 계획/스케줄하는 데 도움을 주며 변경 제어 관리자 역할이 결과물에 대한 변경을 제어하는 데 도움을 주는 책임을 맡습니다. 필요한 경우 다른 역할에도 도움을 줄 수 있습니다. |
표 3: 소형 프로젝트에서 XP 역할을 RUP 역할에 맵핑
RUP는 특정 프로세스가 구성된 후 인스턴스화될 수 있는 프로세스 프레임워크입니다. RUP가 구성되어야 합니다. 이것은 RUP 자체에 정의된 필수 단계입니다. 엄격히 말해, 조정된 RUP 버전을 XP와 비교해야 합니다. 즉, XP가 명시적으로 구축한 프로젝트 특성(및 추론될 수 있는 프로젝트 특성)에 맞게 조정된 RUP와 비교해야 합니다. 이렇게 조정된 RUP 프로세스는 많은 XP 프랙티스(예: 페어 프로그래밍, 테스트 우선 설계 및 리팩토링)를 적응시킬 수 있지만, RUP가 구조, 추상(모델링), 위험 및 시간적 다른 구조(단계 및 반복)의 중요성을 강조하므로 여전히 XP와 동일하지는 않을 것입니다.
XP의 방향은 의도적으로 소규모 프로젝트를 위한 경량의 프로세스를 구현하는 데 있습니다. 따라서 완전히 구현되지 않은 설명(책에 포함된 최소 내용)도 포함합니다. XP 구현에는 서둘러 발견하거나 조작하거나 정의해야 하는 것이 항상 있습니다. RUP는 규모 및 유형에서 XP의 범위에 맞거나 넘어서는 프로젝트를 적응시킵니다. 이 로드맵에 표시된 것처럼, RUP는 실제로 XP 문헌에 설명된 대부분의 프랙티스와 완전히 호환 가능합니다.
XP의 본질이 조직, 사람 및 문화에 초점을 두고 있음을 유념하십시오. 이것은 모든 프로젝트에 중요하며 RUP를 사용하는 프로젝트에 확실히 적용할 수 있습니다. 소형 프로젝트는 이러한 프랙티스를 함께 사용하여 크게 이익을 얻을 수 있습니다.
Rational Unified Process
|