목적
  • 프로젝트의 특정 요구사항에 따라 소프트웨어 개발 프로세스의 크기를 알맞게 조정하는 것입니다.
  • 프로젝트 구성원에게 관련된 액세스 가능한 프로세스 설명을 제공하는 것입니다.
역할:  프로세스 엔지니어 
빈도: 많은 작업이 프로젝트가 시작될 때 수행됩니다. 임의의 주기에서 필요에 따라 반복할 수 있습니다.
단계
입력물:  결과물: 
툴 강좌: 
추가 정보: 

워크플로우 세부사항: 

프로젝트 분석 페이지 맨 위

목적:  가까운 장래의 문제점과 프로젝트에 사용 가능한 자원을 파악하는 것입니다.

개발 프로세스가 가까운 장래의 프로젝트 및 프로젝트의 크기 및 형식 요구사항과 관련되어 있는 것이 프로젝트 성공에 결정적입니다. 너무 많은 프로세스는 창의성과 효율성을 떨어뜨리기 쉽습니다. 너무 적은 프로세스는 일반적으로 비효율, 불일치 및 불예측 결과로 이어지는 지엽적 의사결정으로 각 프로젝트 구성원을 이끌어 혼란스러운 환경을 만들 수 있습니다.

프로세스 형식은 여러 개발 조직에서 상당히 다양합니다. 일부는 프로세스가 매우 발달되어 전담 프로세스 그룹에서 조직 전체의 개발 프로세스를 정의하고 개선합니다. 나머지는 프로젝트 특정 사용자 정의에 대해서만 관여합니다. 이러한 프로젝트는 일반적으로 RUP 제품과 수반되는 사전 정의된 형상 중 하나로 시작하여 거기에서부터 모든 프로젝트의 프로세스를 설명합니다. 프로젝트에 대한 프로세스를 사용자 정의하는 데 사용되는 방법은 다음 몇 가지 요인에 의해 상당히 좌우됩니다.

  • 개발 조직의 프로세스 성숙도.
  • 일정 시간 및 개발 자원 수 측면에서 프로젝트 크기.
  • 이전에 유사한 프로세스에 노출된 프로젝트 구성원.
  • 프로젝트의 형식 요구사항.

자세한 정보는 가이드라인: 프로세스 판별을 참조하십시오.

프로세스 범위 정의 페이지 맨 위

목적:  프로젝트 특정 프로세스에서 다룰 프로세스 영역에 대해 정의합니다.

프로젝트 자원 및 유사한 소프트웨어 개발 프로젝트 경험을 분석한 결과는 사용자 정의 노력 범위를 지정할 때 도움이 됩니다. 프로젝트 특정 프로세스는 RUP의 모든 규칙을 포함할 필요도 없고 RUP에 정의된 모든 역할을 다룰 필요도 없습니다. RUP는 광범위한 프로젝트 유형에 적절한 프로세스 프레임워크이므로 한 가지 특정 프로젝트가 따르기에는 너무 많다는 것에 유의하십시오. 프로젝트 프로세스에서 다루기로 선택한 영역은 프로젝트 구성원이 보유하는 기술력과 프로젝트 특성에 상당히 좌우됩니다. 다음은 사용자 정의 노력 범위를 정의할 때 고려해야 하는 몇 가지 일반적인 사항입니다.

  • 새 프로세스와 툴을 도입할 필요가 없이 프로젝트 구성원이 이미 공통 작업 방식을 보유하는 영역. 예를 들어, 테스트 방법을 알고 있는 경우 새 요인 수를 제한하는 RUP의 테스트 규칙을 도입하는 것은 바람직하지 않을 수 있습니다. 기존 프로세스의 문제점을 정정하기 위해 RUP의 일부를 도입하는 데 초점을 맞출 수 있습니다. 자세한 정보는 ../workflow/environm/co_iproj.htm#Improving Process and Tools -- This hyperlink in not present in this generated website개념: 프로젝트의 프로세스 구현, 섹션 "프로세스 및 툴 개선"을 참조하십시오. 
  • 기존 작업 방식이 없기 때문에 프로젝트에서 새 프로세스 및 툴을 도입해야 하는 분야(규칙). 어떤 경우 의지할만한 기존 프로세스와 툴이 없으면 지원 툴과 함께 대부분의 RUP를 도입해야 합니다. 자세한 정보는 ../workflow/environm/co_iproj.htm#Change Everything -- This hyperlink in not present in this generated website 개념: 프로젝트의 프로세스 구현, 섹션 "모든 사항 변경"을 참조하십시오.  
  • 기존 프로세스의 문제점. 조직에 문제점이 있는 분야의 개선에 초점을 둡니다.
  • 사용할 툴? 프로젝트에서 특정 툴을 사용하기로 결정한 경우 개발 프로세스는 일반적으로 RUP의 해당하는 영역을 다루어야 합니다.
  • 프로젝트의 변경 용량. 조직의 문제점을 바라볼 때 특히 이러한 문제의 다수가 한꺼번에 발생한 경우 한 번에 모든 것을 수정하려는 경향이 있습니다. 이것은 보통 치명적인 함정입니다. 개인들과 같은 조직은 오직 제한 범위 내에서만 변경을 수용할 수 있습니다. 변경 용량이 적은 경우 속도를 늦추고 첫 번째 프로젝트에서는 오직 하나 또는 두 가지의 RUP 규칙을 도입할 수 있습니다.
  • 프로젝트 구성원에게 정보가 부족하거나 취약한 분야. 개발 프로세스에서 이러한 영역을 다루십시오. RUP에서 적절한 정보를 찾는 것은 쉽습니다.

식별된 개선 분야는 동일한 프로젝트에서 처음으로 반드시 도입할 필요는 없습니다. 알 수 없는 요인 수를 줄이고 개발 조직이 과거에 가장 힘들었던 분야를 찾아보십시오. ../workflow/environm/co_iproj.htm -- This hyperlink in not present in this generated website개념: 프로젝트의 프로세스 구현에 설명된대로 반복적으로 RUP를 구현하는 것이 바람직합니다. 몇 가지 규칙 안에서 개선 요구사항이 발견되었을지라도 모든 것을 한 번에 변경하는 방법을 목표로 삼기보다 몇 가지 프로젝트 과정 중에 반복적으로 도입하는 옵션을 고려하십시오.

이렇게 균형을 맞추는 것의 한 예로, 이전 프로젝트가 불명료하거나 불충분한 요구사항으로 골치를 앓았거나 일반 사용자의 주요 불만이 전달된 제품이 자신들의 요구사항을 반영하고 있지 않은 것인 경우 유스 케이스로 요구사항을 소개하고 새 CM 프로세스의 도입을 연기하는 것을 들 수 있습니다.

이러한 사항은 문서화하여 외부 스테이크홀더와 범위 결정에 대해 논의해야 합니다. RUP Builder 제품에서 형상을 작성할 때 이러한 의사결정은 형상에 대한 설명으로 문서화할 수 있으며 공개된 웹 사이트에 올릴 수 있습니다.

프로세스 프레임워크 확장(선택적) 페이지 맨 위

목적:  프로젝트에 대한 RUP 프로세스 프레임워크 범위가 불충분한 영역에서 프로젝트 특정 프로세스에 추가 프로세스 노하우를 추가하는 것입니다.

RUP 프로세스 프레임워크 장점 중 하나는 광범위한 프로젝트 및 환경에 적용할 수 있다는 것입니다. 그러나 이것은 프로세스 설명이 너무 일반화될 수 있기 때문에 동시에 단점으로 인식될 수도 있습니다. RUP 플러그인 테크놀러지는 툴 또는 테크놀러지 벤더 및 개별 회사가 플러그인을 통해 보다 특정적인 프로세스 설명을 작성할 수 있게 하여 이러한 몇 가지 사안을 극복하도록 설계되었습니다. developerWorks®: Rational®의 RUP 섹션에 다운로드할 수 있는 최신 플러그인 목록이 있습니다.

../res_processworkbench.htm -- This hyperlink in not present in this generated websiteRPW(Rational Process Workbench)™ 제품을 사용하면 RUP 플러그인 기술을 사용하여 RUP 확장을 작성할 수 있습니다. 이 테크놀러지의 권장사항을 따라서 RUP 프레임워크는 두 가지 방식으로 확장될 수 있습니다. RUP 프로세스 모델을 확장하는 구조적 플러그인을 작성하거나 씬 플러그인을 통해 개발 조직의 재사용 가능한 관련 자산을 프로젝트에 제공하는 확장을 작성할 수 있습니다.

RUP 플러그인(구조적) 작성은 별도의 계획, 예산 및 제어 메커니즘을 사용하여 자체 권한의 프로젝트로 다루어야 합니다. 투자 수익 분석에 기초하여 비즈니스 케이스를 정의해야 합니다. 실제 플러그인의 개발은 RUP의 라이프사이클 및 규칙을 따르면 유익합니다. 프로젝트를 시작하여 플러그인을 개발하기 전에 플러그인 뒤의 실제 프로젝트에 대한 기본 아이디어를 잘 살펴보는 것이 바람직합니다.

자세한 정보는 ../workflow/environm/co_polpr.htm#Extend -- This hyperlink in not present in this generated website가이드라인: RUP 사용자 정의, 섹션 RUP 확장을 참조하십시오.

프로세스 구성 페이지 맨 위

목적:  정확한 프로젝트 요구사항을 지원하기 위해 프로세스를 조정하는 것입니다.

RUP 프레임워크는 프로세스 컴포넌트 및 플러그인 세트를 빌드합니다. 각 컴포넌트는 관련된 프로세스 요소를 포함합니다. RUP 형상 작성은 프로세스 컴포넌트 세트 중에서 선택한다는 것을 의미합니다. 지정된 프로젝트에 적절한 컴포넌트 세트를 선택하는 것은 매우 중요한 타스크입니다. 효과적으로 선택하기 위해 프로세스는 프로젝트 크기(자원 및 일정 시간), 형식, 테크놀러지 플랫폼, 영역 등과 같이 여러 가지 차원에 따라 관련되고 조정되어야 합니다.

RUP 구성에 대한 자세한 정보는 다음을 참조하십시오.

프로젝트에 대한 프로세스 준비 페이지 맨 위

목적:  구성된 프로세스가 프로젝트에서 규정되는 방식을 정의하는 것입니다.

프로젝트에 구성된 프로세스 설명은 종종 규정할 준비가 된 세부 레벨이 아닙니다. 예를 들어, 프로세스는 관련 프로세스 컴포넌트의 선택을 기준으로 사용할 결과물 세트를 정의하지만(이전 섹션 RUP 형상 작성에 설명된대로), 이 특정 프로젝트에 대한 결과물의 시기 및 형식 요구사항을 지정하지는 않습니다. 규정하는 가이드라인 및 부분적으로 설명된 결과물 템플리트도 설명된 프로젝트 특정 프로세스의 일부로 간주됩니다. 이 단계를 수행하는 데 필요한 노력은 구성된 프로세스의 정밀도에 상당히 좌우됩니다. 기본적인 프로세스와의 이러한 편차는 프로젝트 특정 프로세스의 일부로서 정당화되고 문서화되어야 합니다.

하위 주제:

라이프사이클 명세 정의 프로세스 준비

프로젝트에 관해 구성된 프로세스를 설명하는 작업에는 단계 및 주기로 분류하는 것을 포함하여 프로젝트가 따라야 하는 라이프사이클 모델에 대해 결정하는 것이 포함됩니다. 사용자 정의 작업의 이 부분에서 프로세스 엔지니어는 선택한 라이프사이클 모델이 프로젝트 계획 프로세스의 바탕이 되기 때문에 프로젝트 관리자와 밀접하게 협동해야 합니다. 프로젝트 특성에 따라 특정 요구사항에 보다 잘 맞게 RUP 라이프사이클을 조정하고자 할 수 있습니다. 예를 들어, 녹색 지대 개발은 일반적으로 유지보수 프로젝트보다 초기에 더 많은 노력이 요구됩니다. 따라서 라이프사이클 설명은 프로젝트 특성에 맞춰져야 합니다. 여러 가지 유형의 라이프사이클 모델에 대한 논의는 개념: 주기를 참조하십시오.

결과물 사용자 정의 페이지 맨 위

구성된 프로세스에는 프로젝트에서 생성될 결과물에 대한 설명이 들어 있습니다. 형상은 특정 유형의 프로젝트에 맞도록 정의되어 있기 쉬우므로 이 선택은 설명 프로세스의 일부로 제기되어야 합니다. 왜 필요한지 설명할 수 없는 경우 결과물 생성을 계획하지 마십시오. 또한 결과물은 다음과 같은 정보로 규정되어야 합니다.

  • 이 결과물이 작성 또는 갱신될 단계
  • 필요한 결과물의 형식(예: 고객에 의해 사인오프되어야 하는지 여부)
  • 결과물 생성에 사용해야 하는 툴

이 정보는 스프레드시트 또는 프로세스 웹 사이트에서 액세스할 수 있는 문서로 보관하거나 프로세스 설명의 통합 부분으로 작성할 수 있습니다.

프로젝트에 대한 결과물 자원 준비 페이지 맨 위

프로젝트 특정 프로세스의 일부로서 프로젝트 결과물 생성에 특정 도움말 및 참조 자료를 제공하는 사용자 정의된 사용 가능한 자원 세트가 있어야 합니다. 이러한 자원의 예는 다음과 같습니다.

  • 특정 결과물을 생성하는 방법에 대한 공통 가이드라인(예: 유스 케이스 모델링 가이드라인)
  • 프로젝트에 걸쳐 사용할 사용자 정의된 템플리트. 이들은 프로젝트 정보에서 부분적으로 설명됩니다.
  • 프로젝트의 산출물 및 선택된 테크놀러지의 정의된 세트에 관련된 결과물 예
  • 재사용할 수 있는 자산(예: 설계 패턴 및 코드 라이브러리)

프로젝트가 시작될 때 프로젝트 관리자는 일반적으로 프로세스 엔지니어와 함께 작업하여 적절한 자원 세트를 선택하고 프로젝트 특정 프로세스의 일부로서 프로젝트 구성원에게 사용 가능하게 합니다. 추가 자원에 대한 요구는 각 주기가 시작될 때 재고됩니다.

프로젝트 구성원에게 프로세스 소개 페이지 맨 위

목적:  프로젝트 특정 프로세스를 프로젝트 구성원이 사용할 수 있게 하는 것입니다.

초기 사용자 정의 작업이 완료되면 결과로서 발생한 프로세스를 사용 가능한 형식으로 출력해야 합니다. RUP Builder 제품은 선택한 프로세스 컴포넌트 및 자원만 포함하는 결과적으로 발생한 구성된 프로세스를 RUP 웹 사이트에 출력하는 수단을 제공합니다. 프로세스 엔지니어는 프로젝트 관리자와 함께 작업하여 프로젝트 특정 프로세스를 공용으로 만들고 프로젝트 구성원의 훈련 방법을 결정해야 합니다. 이것은 프로젝트 크기와 프로젝트 구성원의 유사한 개발 프로세스에 대한 친숙성 정도에 따라 비공식적인 2시간 프리젠테이션에서 보다 공식적인 훈련에 이르기까지 다양할 수 있습니다. 프로젝트 라이프사이클 중에 모든 중요한 프로세스 갱신은 변경에 초점을 두고 프로젝트에 다시 착수되어야 합니다.

프로젝트 특정 프로세스의 웹 사이트는 조직 네트워크의 웹 서버에 공개하거나 각 개별 팀 구성원의 컴퓨터에 설치할 수 있습니다. 프로젝트 구성원이 대부분 네트워크에 연결되어 있는 경우 RUP 웹 사이트를 웹 서버에 배치하는 것이 프로세스 라이프사이클 중에 프로세스 갱신과 연관된 오버헤드를 피하는 좋은 방법입니다.

프로세스 유지보수페이지 맨 위

다수의 사용자 정의 작업이 프로젝트 초기에 완료되지만 프로젝트 팀이 프로세스에서 장애 및 기타 사안을 발견할 때마다 최신으로 계속 유지해야 합니다. 프로젝트 중에 작성되는 평가는 프로세스 향상에 중요한 정보가 됩니다. 사소한 조정은 일반적으로 프로젝트에서 처리되지만 프로젝트 특정 프로세스에 대한 갱신은 다가오는 주기의 개발 환경 준비의 일환으로 이루어집니다. 보다 복잡한 사안은 프로세스에 대한 변경 요청으로 제기됩니다. 이것은 보통 조직상의 기초에서 소프트웨어 개발 프로세스의 책임을 가진 프로젝트 경계 밖의 프로세스 그룹에서 처리됩니다.

주기적 개발의 주요 장점 중 하나는 프로젝트 팀이 점차적으로 소프트웨어 개발 방식을 향상시킬 수 있다는 점입니다. 모든 프로젝트가 다음 단계로 구성되는 프로세스 엔지니어링 마이크로 사이클을 포함하는 것이 좋습니다.

  • 프로세스 정의
  • 정의된 프로세스에 기초하여 프로젝트 작업 수행
  • 작업 평가
  • 프로세스 정제

../res_processworkbench.htm -- This hyperlink in not present in this generated websiteRational Process Workbench 제품안의 프로세스 엔지니어링 프로세스에는 조직 설정의 프로세스 향상에 대한 정보가 들어 있습니다.



Rational Unified Process   2003.06.15