이 가이드라인은 환경 원칙에 설명된 활동을 수행하여 소프트웨어 개발 프로젝트의 프로세스 및 도구를 구현하는 방법을 설명합니다. 프로젝트 계획, 위험성 식별 및 프로젝트의 관리,
모니터링과 평가를 다루는 프로젝트 관리 원칙도 논의합니다.
"프로세스 및 도구 구현 접근 방식"에 설명된 대로 프로세스와 도구를 구현하는 여러 방식이 있음을 이해해야
합니다. 선택하는 접근 방식은 프로젝트의 현재 상태와 주변 조직에 따라 달라지므로, 프로젝트 및 주변 조직에 대한 평가를 수행하십시오( 중간 산출물: 개발 조직 평가 참조).
이 가이드라인은 프로젝트의 프로세스를 구현하기 위한 일부 가능한 접근 방식을 설명합니다. 또한 개념: 환경
사례에서는 소프트웨어 프로젝트의 환경을 구현하는 데 유용한 일부 근본적인 사례를 설명합니다. 프로세스 구현의 프로세스 사용자 조정 측면에 대한 자세한 정보는 RUP 사용자 조정을 참조하십시오.
다음 일반 가이드라인은 거의 모든 프로젝트에 적용됩니다.
-
프로젝트 시작 전에: 프로젝트를 실제로 시작하기 전에 Rational Unified Process(RUP)에서 프로세스 엔지니어, 도구 전문가 및 프로젝트 관리자 역할을 수행하는 이들을
훈련시켜야 합니다. 이는 프로젝트 성공의 열쇠입니다. 프로젝트 구성원이 수행할 사항을 모른다면 성공은 불가능할 것입니다.
-
도입/인식(Inception) 단계: 이 단계 중에는 일반적으로 요구사항을 관리하는 방식을 개선하는 방법(요구사항 원칙) 및 프로젝트 관리 방법(프로젝트 관리 원칙)을 이해하는 데 초점을
맞춥니다.
-
정제(Elaboration) 단계: 정제 단계가 끝날 무렵에는 모든 프로세스와 도구가 자리 잡힙니다. 이 단계의 가장 중요한 부분은 종종 구성 및 변경 관리의 수행 방법이며,
구현/구축(Construction) 단계에서 동시에 작업하는 개발 팀이 해당 작업을 수행하게 됩니다.
-
구현/구축(Construction) 단계: 이 단계에서는 새 프로세스나 도구가 도입되지 않습니다. 이 단계의 중점 작업은 제품의 생산이기 때문에 개발 환경이 안정적이어야 합니다. 구현/구축
단계에서 동기 부여는 최신 프로젝트에 대해 새로운 인력에게 미리 설명하는 것입니다.
-
전이(Transition) 단계: 새 프로세스나 도구가 도입되지 않습니다. 전이 단계에 접어들면 작업의 초점이 프로젝트 특정 프로세스 개선에서 프로젝트 사후 검토로 이동하면서, 현재
프로젝트로부터 프로젝트 경험을 수집하여 요약한 다음 이후 프로젝트에서 사용할 수 있는 형태로 패키징합니다. 이렇게 수집된 경험은 다음 제품 전개를 개발하기 위한 프로세스와 도구 개선에 대한 입력으로
사용됩니다.
프로세스 의식(ceremony)은 여러 다른 개발 조직에서 상당히 달라집니다. 일부는 프로세스가 매우 성숙하여 전담 프로세스 그룹에서 조직 전체의 프로세스를 정의하고 개선합니다. 나머지는 프로젝트 특정 사용자
조정에만 관여합니다.
프로젝트에 대한 프로세스를 사용자 조정하는 데 사용되는 접근 방식은 조직의 프로세스 의식(ceremony) 및 기타 여러 요인에 의해 상당히 좌우됩니다. 예를 들어 다음과 같습니다.
프로세스 구현에 영향을 미치는 요인에 대한 자세한 정보는 가이드라인:
프로세스 판별을 참조하십시오.
다음은 소프트웨어 개발 프로젝트에서 프로세스와 도구를 구현하는 기본 접근 방식입니다.
-
"전체 변경". 이는 프로젝트가 전체 RUP 및 새 도구의 전체 세트를 채택함을 의미합니다.
-
"프로세스 및 도구 개선". 이는 프로젝트에서 RUP 및 지원 도구의 일부를 채택해서 프로세스와 도구의 일부 영역을
개선하기로 결정했음을 의미합니다.
특정 프로젝트에서 RUP를 어느 정도 채택하고 새 도구를 얼마나 많이 구현하는가의 여부는 많은 요인에 따라 다릅니다. 이러한 요인은 가이드라인:
프로세스 판별에서 설명합니다. 이들은 프로젝트와 주변 조직을 평가하는 동안에는 일반적으로 다루지 않는 요인입니다. 이 정보는 중간 산출물: 개발 조직 평가에서 캡처됩니다.
프로젝트는 다음 중 한 가지 또는 여러 이유로 인해 전체 RUP를 채택하고 새 도구 세트를 사용하기로 결정할 수 있습니다.
-
자리 잡힌 프로세스나 도구가 없는데 프로젝트에 전체 프로세스와 모든 도구가 필요합니다.
-
전체 또는 대부분의 사람들이 새로 고용되어 공통으로 승인된 작업 방식이 존재하지 않습니다.
-
프로젝트가 조직의 새 기술로 이동해서 기존 프로세스와 도구가 더이상 사용되지 않습니다.
프로젝트에 전체 RUP와 도구를 도입하기로 결정한 경우에는 프로세스와 도구를 점진적으로 구현해야 합니다. 단계별 프로시저로 프로세스와 도구를 구현하면 보다 쉽게 위험성을 관리하고 프로젝트의 인원들이 변경에 대해 덜
당황하게 됩니다. 다음 다이어그램은 프로젝트의 라이프사이클 동안 다른 환경 중간 산출물이 개발될 시기를 설명합니다.
"모든 것이 새로운" 프로젝트에서의 환경 중간 산출물 전개.
계획에 대한 설명:
-
전체: 비즈니스 모델링 원칙이 전부 생략됩니다.
-
도입/인식: 요구사항 및 프로젝트 관리 원칙의 도입에 초점을 맞추십시오. 새 요인의 수를 줄이기 위해 요구사항의 사용자 인터페이스 부분은 도입하지 않습니다. 프로젝트 관리자는 사용할 프로젝트
관리 원칙의 부분을 결정합니다.
-
정제 반복 E-1: 정제 단계에서는 분석 및 디자인 및 아키텍처가 가장 중요합니다. 프로젝트 구성원의 수가 상대적으로 적기 때문에 프로젝트의 초반에 비해 자동화된 테스트 및 구성 및 변경 관리가
그리 중요하지 않습니다. 이는 프로젝트의 후반부에 도입할 수 있습니다.
-
정제 반복 E-2: 테스트를 자동화하기 위해 테스트 도구 및 프로세스가 도입됩니다. 요구사항 변경을 관리하기 위해 Rational RequisitePro가 도입됩니다.
-
정제 반복 E-3: 구현/구축 단계에서는 동시에 작업하는 개발 팀이 작업을 수행합니다. 따라서 정제 단계가 끝날 무렵에는 구성 및 변경 관리 원칙이 자리 잡혀야 합니다. 배치 관리자는 배치
원칙의 원칙 수행 방법을 결정합니다.
-
구현/구축: 새로 도입되는 사항이 없습니다. 환경 관점에서 구현/구축 단계의 초점은 프로젝트에 대해 모든 새 인력에게 미리 설명하는 것입니다.
-
전이: 새로 도입되는 사항이 없습니다. 프로세스와 도구가 필요에 따라 정제됩니다.
프로세스와 도구가 자리 잡힌 조직에서 프로젝트의 인력은 시스템을 개발할 능력이 있습니다. 이들은 어느 정도 잘 문서화된 프로세스인 공통 작업 방식을 가지고 있습니다.
장기 목적은 전체 RUP 및 전체 새 도구 세트를 채택하는 것일 수 있습니다. 그러나 단기 목적은 프로세스와 도구 지원의 하나 또는 여러 영역을 개선하는 것입니다. 이는 높은 개선 잠재력이 있는 영역이어야
합니다.
아래의 그림은 RequisitePro 및 Rational Rose와 같은 도구와 함께 요구사항 원칙을 채택해서 요구사항 관리 방식을 개선하기로 결정한 프로젝트의 예제입니다. 프로젝트에서는 분석 및 디자인 원칙도
도입하기로 결정했습니다.
요구사항 및 분석 및 디자인을 개선할 때 환경 중간 산출물의 전개.
위의 다이어그램은 예제일 뿐임을 이해해야 합니다. 개선하기로 결정한 프로세스의 파트는 특정 프로젝트의 문제와 요구에 따라 프로젝트 간에 차이가 있습니다. 프로젝트 및 주위 조직을 평가하여 개선하려는 프로세스의
파트나 도입하려는 도구를 찾아 보십시오.
다음은 요구사항 원칙이 도입되는 도입/인식 단계의 반복 예제입니다. 간트 차트의 각 항목은 다이어그램 다음에 자세히 설명합니다.
도입/인식 단계의 반복 예제
일반 RUP 도입/인식에 대해 설명된 기본 워크플로우는 이러한 변형 및 확장과 함께 적용됩니다.
프로젝트 관리
초기 아이디어 도출 단계에서 포기할 지 또는 계속할 지 여부에 대한 결정이 가능한 시점으로 프로젝트를 가져오십시오. 주요 결과는 중간
산출물: 비즈니스 사례, 중간
산출물: 소프트웨어 개발 계획 및 중간
산출물: 위험성 목록의 초안입니다.
새 프로세스 및 도구의 구현과 연관된 위험성을 포함하여 프로젝트의 위험성을 식별하십시오. 결과는 중간
산출물: 위험성 목록입니다.
단계를 계획하십시오. 주요 결과는 소프트웨어 개발 계획의 프로젝트 계획이라는 제목의 섹션입니다. 이 섹션은 환경 원칙에 대한 기준을 포함하여 달성
기준과 함께 주요 이정표를 찾을 수 있는 단계 계획을 포함합니다.
참고: 사용자 조정된 개발 프로세스와 소프트웨어 개발 계획은 서로에게 큰 영향을 미칩니다. 따라서 프로세스의 사용자 조정 및 프로젝트 계획의 개발을
조정해야 합니다.
환경 원칙과 다른 모든 원칙을 포함하여 반복을 자세히 계획하십시오. 주요 결과는 다른 모든 프로세스 원칙 뿐 아니라 환경 원칙의 모든 활동 세부사항 및 타스크를 포함한 중간 산출물: 반복 계획입니다.
프로세스 및 도구의 사용은 반복 평가의 일부로 평가됩니다. 결과는 다음과 같습니다.
프로젝트 관리자는 프로세스와 도구를 포함하여 일일 작업을 모니터합니다.
반복이 끝나면 프로세스 및 도구와 연관된 위험성을 포함하여 위험성이 다시 평가됩니다. 일부 위험성은 반복 중에 이주되고 새 위험성이 식별됩니다. 주요 결과는 갱신된 중간 산출물: 위험성 목록입니다.
요구사항
특별한 변경사항이 없습니다.
테스트
테스트 노력 자원 조달에 대한 초기 추론을 제공하는 중간
산출물: 테스트 전략의 일부 물류 측면이 정의됩니다.
테스터의 소규모 팀과 테스트 디자이너는 테스트 접근 방식의 핵심 요소가 컴포넌트 중간 산출물: 아키텍처 개념 검증에 대해 동작하고 써드파티 컴포넌트 선택사항이 테스트 가능하다고 검증되는지
확인합니다.
환경
조직의 현재 상태를 평가하고 첫 번째 반복에서 중점을 두려는 도구 및 프로세스의 파트를 결정하십시오. 이 경우에는 프로젝트가 평가에 기초해서 프로세스와 도구의 구현을 시작하기로
결정했습니다.
참고: 소프트웨어 개발 계획과 사용자 조정된 개발 프로세스는 서로에게 큰 영향을 미칩니다. 따라서 프로세스의 사용자 조정 및 프로젝트 계획의
개발을 조정해야 합니다.
결과는 다음과 같습니다.
요구사항 원칙에 대한 프로세스 및 도구와 함께 지원 도구를 준비하여 프로젝트의 구성원이 이를 사용할 수 있도록 하십시오. (물론 기타 원칙도 준비할 수 있습니다.) 타스크: 프로젝트의 개발 프로세스 사용자 조정을 참조하십시오.
프로젝트의 구성원이 개발 프로세스, 유스 케이스 모델링 가이드라인 및 도구의 사용 방법을 이해하게 하십시오. 표준 훈련 과정 외에 프로젝트 구성원이 실무 경험을 얻을 수 있는 일일 워크샵을 권장합니다. 타스크: 개발 프로세스 시작을 참조하십시오.
활동 수행 결과는 다음과 같습니다.
-
다음을 포함한 요구사항 원칙이 자세히 설명되어 있는 개발 프로세스
-
-
요구사항
도구가 프로젝트의 구성원이 사용할 수 있도록 설정 및 준비됩니다.
시스템 관리자는 반복 중에 개발자를 지원합니다.
훈련
-
프로젝트의 모든 구성원이 RUP의 개요를 제공하는 과정에 참여하여 프로젝트의 라이프사이클 개요를 알아야 합니다.
-
"적용 중"인 RUP 원칙에 대해 작업하는 인원은 원칙의 세부사항을 학습하는 과정에 참여해야 합니다.
조언
조언은 성공적인 프로세스 구현의 열쇠입니다. 일반적으로 다음 조언자가 필요합니다.
-
프로세스 조언자 50%. 프로젝트에서 프로젝트 관리자 및 기타 구성원의 프로세스 사용과 구성을 지원하는 프로세스 엔지니어 역할을
수행하는 사람
-
<원칙 특정> 조언자 50%. 워크샵을 주최하고, 결과를 검토하고, 특정 질문에 응답해서 원칙 특정 작업을 수월하게 하는
사람
조언에 대한 자세한 정보는 개념: 조언을 참조하십시오. |