타스크: 개발 사례 개발
이 타스크는 조직 또는 프로젝트에 대한 소프트웨어 개발 프로세스를 설명하는 개발 사례 작성 방법에 대해 설명합니다.
원칙: 환경
관계
역할기본 수행자: 추가 수행자:
입력필수:
  • 없음
선택사항:
출력
프로세스 사용법
단계
각 원칙 수행 방법 결정

특정 프로젝트에서 사용할 RUP 프레임워크를 사용자 조정하는 작업 중 하나는 도입할 원칙을 결정하는 것입니다. 타스크: 프로젝트의 개발 프로세스 사용자 조정에 설명된 대로 한 개의 단일 프로젝트에서 모든 RUP를 사용해서는 안 됩니다. RUP에 기술된 사례가 생소하여 프로젝트에 적용하기 어려운 경우, 팀이 새 프로세스 플랫폼으로 쉽게 이전할 수 있도록 알 수 없는 요인 수를 적은 수로 제한하는 데 초점을 맞춰야 합니다.

도입해야 할 훈련을 결정한 후에는 각각에 대해 다음 사항을 결정하십시오. 

  • 워크플로우 수행 방법 
  • 사용해야 할 워크플로우 파트 
  • 프로젝트 라이프사이클 동안 워크플로우 및 파트 도입 시기 

결정을 돕기 위해 "<원칙 X>에 대한 중요한 결정"이라는 각 원칙에 대한 가이드라인이 개발되었습니다. 이 가이드라인에는 "워크플로우 수행 방법 결정"이라는 섹션이 있습니다. 이 구성에 포함된 원칙에 대해서는 첨부된 가이드라인을 참조하십시오.

특정 원칙이나 그 중 하나를 도입하려는 경우 다음 사항을 고려하십시오.

  • 적용 가능성. 프로젝트에 적용 가능합니까? 원칙 도입 시 실제로 가치가 부가됩니까?
  • 문제점 및 근본 원인이 해결됨. 감지된 문제점과 근본 원인을 해결합니까?
  • 도구 지원. 필요한 도구 지원에는 어떤 것이 있습니까?
  • 타이밍. 프로젝트 라이프사이클 중 원칙 도입 시기는 언제입니까? 자세한 내용은 개념: 프로젝트의 프로세스 구현을 참조하십시오.
  • 구현 비용. 프로젝트에서 원칙 구현에 드는 비용은 얼마입니까? 이는 다음과 같습니다.
    • 프로젝트 구성원 교육 비용 
    • 지원 도구 설치 비용
    • 가이드라인 및 템플리트 개발 비용
원칙당 아티팩트 사용자 조정

생성할 프로젝트의 올바른 중간 산출물 세트를 선택하십시오. 중간 산출물을 생성해야 하는 이유를 명확하게 설명할 수 없는 경우, 예를 들어 외부 이해 당사자(stakeholder)가 중간 산출물을 요청하지 않은 경우 해당 중간 산출물을 제외시키십시오.

개발 사례를 사용하여 기본 프로세스에서 파생된 사항을 문서화하는 것은 좋은 방법이므로, 중간 산출물을 제외시키는 것을 정당화하고 문서화해야 합니다.

다음 단계를 수행하십시오.

  1. 중간 산출물(모델링 요소 또는 문서) 사용 방식을 결정하십시오. 개별 중간 산출물의 중요성 및 사용 여부를 설명하는 분류 계획에 대한 정보는 가이드라인:중간 산출물 분류를 참조하십시오.
  2. 각 중간 산출물의 검토 레벨을 결정하고 "검토 세부사항"에 이를 캡처하십시오. 자세한 내용은 가이드라인: 검토 레벨을 참조하십시오. 각 중간 산출물을 검토하는 방법 즉, 사용할 검토 프로시저를 결정하십시오.  
  3. 원칙의 최종 결과를 캡처하는 방식을 결정하십시오. 결과를 종이에 저장해야 합니까? 그럴 경우 도구에서 결과를 추론하는 보고서를 한 개 또는 여러 개 결정하고 그 결과를 종이에 캡처하십시오.  
  4. 중간 산출물을 개발하고 유지보수하는 데 사용할 도구를 사용하십시오.
  5. 사용할 특성 및 각 특성 사용 방법을 결정하십시오. 각 중간 산출물에 대한 특성 테이블과 각 중간 산출물의 "사용자 조정" 섹션을 참조하십시오.
  6. 관련이 있는 경우 사용할 스테레오타입을 결정하십시오. 각 중간 산출물에 대해서는 "사용자 조정" 섹션을 참조하십시오.
  7. 문서 중간 산출물에 대한 아웃라인을 결정하십시오. 각 중간 산출물에 대해서는 "간략한 아웃라인"을 참조하십시오. 기본 설명 부분입니다.

이 단계 외에도 다음을 수행해야 합니다.

  • 사용할 보고서를 결정하십시오. 모델에서 정보를 추출할 작업 보고서가 필요한지 여부를 결정한 다음 검토를 위해 정보를 종이에 문서화하십시오. 이러한 작업 보고서는 검토가 완료되는 즉시 폐기될 임시 보고서이므로 일반적으로 임시 보고서로 취급됩니다. 아웃라인을 사용자 조정해야 합니다.

이외에도 각 원칙에 대해 결정할 사항이 더 있습니다. 자세한 내용은 각 원칙의 "<원칙 이름>에 대한 중요한 결정"을 참조하십시오.

원칙당 타스크 사용자 조정

수정된 중간 산출물 세트와 타스크를 연구한 다음 이러한 중간 산출물을 사용, 작성 및 갱신하십시오. 이러한 타스크를 수정할지 아니면 단순화할지 여부를 결정하십시오. 각 타스크에 대해 입력 및 출력 중간 산출물이 표시되어 있습니다. 불필요한 단계나 타스크는 삭제하십시오. 다음을 고려하십시오.

  • 추가한 중간 산출물, 보고서 및 문서를 반영할 새 단계와 가능한 새 타스크를 도입하십시오.
  • 사용된 도구가 일부 단계를 용이하게 하거나, 자동화 또는 억제하는 방식을 검사하십시오.
  • 조직의 경험을 통해 전해진 특정 가이드라인과 규칙을 타스크에 도입하십시오. 이들은 안내 사항, 체크리스트, 검토 항목으로 추가되거나 별도의 참조 문서로 보관될 수도 있습니다.
  • 알려진 타스크일 경우 타스크 상호작용을 표시하는 각 원칙과 연관된 워크플로우를 검토하십시오. 필요한 경우 타스크를 제거하거나 추가하십시오.
  • 전체 원칙은 생략하거나 작성할 수 있습니다.
  • 일부 추가 역할을 도입하여 특정 기술을 요구하는 특수한 타스크를 처리해야 할 수도 있습니다.

개발 사례에 변경사항에 대해 설명하십시오.

라이프사이클 모델 선택

프로젝트에서 채택할 라이프사이클 모델을 선택하십시오. RUP 모델을 정제하고 필요한 경우 이정표와 이정표 평가 기준을 조정하십시오. 한 개의 단계나 여러 단계를 생략하거나 이정표를 추가 또는 제거해야 할 수도 있습니다. 자세한 정보와 아이디어에 대해서는 개념: 단계 및 개념: 반복을 참조하십시오. 개발 사례의 "개발 사례 개요" 섹션에서 프로젝트의 라이프사이클 모델을 문서화하십시오.

전체 라이프사이클 모델 선택 이외에도 원칙 워크플로우 수행 방법(수행할 활동과 수행 순서)과 프로젝트 라이프사이클 동안 원칙 워크플로우의 각 파트를 도입하는 시기를 결정하는 것이 중요합니다. 각 RUP 원칙 워크플로우 사용자 조정 방법에 대한 자세한 내용은 각 RUP 원칙에 제공되는 참조 워크플로우용 사용법 노트를 참조하십시오. 개발 사례에 원칙 워크플로우 결정사항을 문서화하십시오.

샘플 반복 설명

각 단계마다 적어도 한 개의 샘플 반복(여러 개를 설명할 가능성이 많음)에 대해 설명하십시오. 이러한 반복 설명은 프로젝트가 서로 다른 반복 및 프로젝트 단계에서 작동하는 방식에 대해 설명합니다. 자세한 예는 RUP 라이프사이클 페이지 아래에 있는 여러 단계 설명을 참조하십시오.

개발 사례에 샘플 반복에 대해 설명하는 목적은 프로젝트가 수행할 타스크와 수행 순서에 대해 프로젝트 팀과 커뮤니케이션하기 위한 것입니다. 이와 같이 샘플 반복은 보다 자세한 반복 계획으로 사용될 수 있습니다. 샘플 반복에 대한 설명은 간략하게 하되, 타스크, 중간 산출물 및 가이드라인에 속해 있는 세부사항은 포함시키지 마십시오. 타스크 또는 작업의 관점에서 샘플 간격에 대해 설명하도록 선택할 수 있습니다. 작업 기반의 설명은 관리 레벨에 있는 계획과 제어에 사용하는 것이 더 쉽지만, 종사자(practitioner) 레벨에서 이들을 사용할 경우에는 타스크 기반의 설명을 사용하는 것이 좋습니다.

대부분의 경우 단계당 최소 한 개의 샘플 반복을 설명해야 합니다. 필요할 때 샘플 반복에 대해 설명하십시오. 프로젝트가 시작할 때 전이 단계에서 작업 방법에 대해 설명할 필요는 없습니다. 먼저 도입/인식(Inception) 단계에서 프로젝트 작동 방식을 정의하십시오.

이해 당사자(stakeholder) 식별

이해 당사자(stakeholder) 역할은 가능한 모든 이해 당사자를 프로젝트에 나타냅니다. 이해 당사자의 여러 유형, 이들의 요구사항 및 책임을 식별하고 설명해야 합니다. 고객 대표, 사용자 대표, 투자자, 프로덕션 관리자, 바이어를 이해 당사자의 예로 들 수 있습니다.

개발 사례의 "역할" 섹션에 여러 이해 당사자와 이들의 요구사항에 대해 설명하십시오.

직책에 역할 맵핑

몇몇 개발 조직에는 직책이 정의되어 있습니다. 이러한 직책이 공통적으로 사용되고 조직에서 널리 수용되는 경우 RUP의 역할과 조직의 직책을 맵핑하는 것이 좋습니다. 직책을 역할에 맵핑하면 조직에 소속된 사람들이 RUP 채택 방법을 보다 쉽게 이해할 수 있습니다. 맵핑을 수행하면 흔히 같다고 오해하기 쉬운 역할과 직책이 서로 다름을 이해하는 데 도움이 됩니다. 개발 사례의 "역할" 섹션에 이 맵핑을 문서화하십시오.

개발 사례 문서화

개발 사례에 대해 설명하십시오. "표시 옵션" 섹션 및 연관된 안내(예: 템플리트 및/또는 예제)를 참조하십시오.

개발 사례 유지보수

프로젝트를 시작하기 전에 여러 가지 사항을 결정해야 합니다. 소프트웨어 개발 프로젝트의 각 반복 이후에 프로세스를 평가하고 결정사항을 다시 고려해야 합니다. 기본 구성의 새 버전이 릴리스된 경우에는 개발 사례를 갱신해야 합니다.

핵심 고려사항


 

대체

자세한 정보