주제

워크플로우 수행 방법 결정 페이지 맨 위

구현 규칙의 워크플로우와 관련하여 다음을 결정해야 합니다.

  • 구현: 워크플로우를 검토하여 워크플로우 수행 방법을 결정하십시오. 감시 조건이 있는 다이어그램 및 아래의 가이드라인을 학습하십시오. 수행할 워크플로우 세부사항 및 순서를 결정하십시오.  
  • 수행할 구현 워크플로우 세부사항의 파트를 결정하십시오. 다음은 비교적 서로 상관 없이 소개될 수 있는 일부분입니다.

워크플로우 파트

설명

통합 및 빌드 관리 결과물: 통합 빌드 계획과 함께 통합자 역할 및 활동: 시스템 통합 계획은 보통 프로젝트 초기에 소개됩니다. 활동: 서브시스템 통합 계획, 활동: 서브시스템 통합활동: 시스템 통합과 같은 기타 통합 관련 활동은 통합이 시작될 때 바로 소개됩니다.  
컴포넌트 구현 구현자코드 검토자 역할, 그리고 해당 활동 및 결과물은 각 반복 작업에서 구현 시작시 소개됩니다.

  • 프로젝트 라이프사이클 동안 워크플로우의 각 파트 소개 시기를 결정하십시오. 종종 전체 구현 규칙을 소개하기 전에 구현화 단계 때까지 대기할 수 있습니다. 시작 단계에서 프로토타입 개발은 보통 예비 단계로 수행하며 구현화 및 구성 중에 완전한 구현 워크플로우에서 요구하는 것처럼 엄격(예: 결과물 및 검토 관련)하게 수행되지는 않습니다.

프로젝트 특정 프로세스의 일부분으로서 결정사항을 문서화하십시오.

결과물 사용 방법 결정 페이지 맨 위

사용할 결과물과 각 결과물의 사용 방법을 결정하십시오. 아래의 테이블은 보유해야 하는 해당 결과물과 일부의 경우에 사용되는 결과물을 설명합니다. 각 결과물 조정 방법에 대한 자세한 정보와 해당 특정 결과물의 장점 및 단점에 대한 설명은 각 결과물의 "조정" 섹션을 읽으십시오.

결과물마다 해당 결과물을 사용해야 하는 방법(보유 필수, 보유 필요, 보유 가능 또는 보유 금지)을 결정하십시오.

결과물 목적

조정(선택사항, 권장사항)

구현 모델

(구현 서브시스템, 구현 요소)

구현 모델은 소스 코드, 실행 파일 및 런타임 환경에서 시스템을 빌드하고 관리하는 데 필요한 기타 모든 결과물입니다.

구현은 코드(소스, 2진 및 실행 파일)를 포함하는 구현 요소 및 정보(예: 시작 파일 또는 Read Me 파일)를 포함하는 파일로 구성됩니다.

구현 서브시스템은 구현 요소 및 기타 구현 서브시스템의 콜렉션이며 상대적으로 작은 파트로 분할하여 구현 모델을 구조화하는 데 사용됩니다.

모든 소프트웨어 프로젝트에는 최소한 일부 소스 코드 및 실행 파일로서 구현 요소가 포함된 구현 모델이 있습니다.

일부 프로젝트는 서브시스템, 라이브러리 및 비주얼 모델도 포함합니다.

서브시스템은 구성될 다수의 구현 요소가 있을 때 유용합니다.

통합 빌드 계획 컴포넌트를 구현해야 하는 순서, 시스템을 통합할 때 작성할 빌드 및 빌드의 평가 방법을 정의합니다.

선택사항.

통합을 계획해야 할 경우에 권장합니다. 통합이 사소한 것일 경우에만 생략하십시오.


각 결과물을 조정하여 프로젝트의 요구에 맞추십시오. 조정 고려사항은 결과물 설명 페이지의 조정 섹션

단위 테스트 커버리지 결정 페이지 맨 위

단위 테스트가 수행될 범위 및 비공식 코드 커버리지에서 100% 코드 커버리지로 이동하는 배율이 있는 코드 커버리지 레벨을 결정하십시오.

단위 테스트 커버리지의 레벨은 종종 코드를 받은 통합 및 시스템 테스터의 필요에 의해 결정됩니다. 시스템 테스터는 작업 코드의 품질에 따라 다릅니다. 코드에 수 많은 결함이 있으면 통합 및 시스템 테스터는 코드를 다시 구현자에게 자주 보내게 됩니다. 이것은 개발 프로세스가 불량하다는 표시이며 구현자가 단위 테스트를 철저하게 수행한 것만이 솔루션이 될 수 있습니다.

물론 단위 테스트 코드에 결함이 전혀 없다고 예상할 수는 없습니다. 그러나 단위 테스트와 품질 간 "최적의" 밸런스를 찾아야 합니다.

단위 테스트 커버리지의 레벨은 여러 다른 단계 사이에서도 다를 수도 있습니다. 다수의 클래스가 해당 단계에서 부분적으로만 구현되므로 구성 및 전이 중에 100% 코드 커버리지를 필요로 하는 안전이 중요한 프로젝트조차 구현화 동안에는 일반적으로 단위 테스트 커버리지를 필요로 하지 않습니다.

코드 검토 방법 결정 페이지 맨 위

코드를 검토해야 하는 범위를 결정하십시오.  

코드 검토의 장점은 다음과 같습니다.

  • 프로젝트에서 공통 코드화 양식을 강제 실행하고 촉진시킵니다. 코드 검토는 프로젝트의 구성원이 프로그래밍 가이드라인을 준수하게 하는 효율적인 방법입니다. 이를 보장하려면 모든 소스 코드 파일을 검토하는 것보다 모든 작성자 및 구현자의 결과를 검토하는 것이 중요합니다.
  • 자동화된 테스트에서 찾지 못하는 오류를 찾을 수 있습니다. 코드 검토에서 테스트시 나타나지 않는 오류를 발견합니다.
  • 개인 간 지식을 공유하고 숙련도에 따라 개인 대 개인으로 지식을 전달합니다.

코드 검토의 단점은 다음과 같습니다.

  • 시간 및 자원이 소모됩니다.
  • 올바르게 수행되지 않으면 비효율적일 수 있습니다. 코드 검토가 "단지 의무적으로" 수행되어 자동화된 테스트를 효과적으로 보완하지 못하는 위험이 있습니다.

코드 검토에 대한 자세한 정보는 활동: 코드 검토를 참조하십시오.

코드 검토는 프로젝트의 가치를 높여 줍니다. 코드 검토와 관련된 버그 및 유지보수 문제점의 레벨을 측정하기 시작하는 모든 프로젝트에서 이 검토로부터 성과를 얻을 수 있습니다. 그러나 다수의 조직에서는 다음과 같은 몇 가지 이유로 인해 프로젝트를 "잠시 중단"하는 것이 어렵습니다.

  • 코드 검토가 실제로 실시되는지 확인하는 데 충분한 데이터가 수집되지 않습니다.
  • 너무 많은 데이터가 수집됩니다.
  • 구현자가 자신의 코드에 대해서는 옹호적입니다.
  • 검토가 형식에 얽매여 난항에 빠지게 됩니다.
  • 검토 관리에 많은 노력이 필요합니다.

코드 검토를 최대한 이용하려면 다음 사항을 명심하십시오.

  • 적당한 데이터만 수집하십시오.
  • 검토에 대한 성과를 측정하고 해당 결과를 표시하십시오.
  • "간결한" 방법으로 검토를 사용하십시오.


Rational Unified Process   2003.06.15