가이드라인: 분석 및 디자인에 대한 중요한 결정
이 가이드라인은 프로세스의 분석 및 디자인 측면을 사용자 조정할 경우 고려해야 할 중요한 사항을 설명합니다.
관계
기본 설명

중간 산출물 사용법 결정

사용할 중간 산출물 및 각 중간 산출물의 사용법을 결정하십시오. 사용할 중간 산출물의 식별뿐만 아니라 각 중간 산출물을 프로젝트의 필요에 맞게 사용하도록 사용자 조정하는 것도 중요합니다.  

아래 표는 권장되는 분석 및 디자인 중간 산출물과 선택사항으로 간주되는 형상 및 변경 관리 중간 산출물(예: 특정 경우에만 사용될 수 있음)을 지정합니다. 추가 사용자 조정 고려사항은 중간 산출물 설명 페이지의 사용자 조정 섹션을 참조하십시오.

중간 산출물 목적

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

분석 모델(분석 클래스) 분석 모델은 디자인 결정을 내리기 전에 요구사항을 더 잘 이해하는 데 유용합니다. 복잡한 시스템에서는 분석 모델을 유지보수하여 시스템의 개념 개요를 제공할 수 있습니다.

선택사항

많은 프로젝트에서 초기 디자인 모델은 분석 모델 대신 사용되었습니다.

분석 모델을 작성하는 프로젝트의 경우 보통 임시 아티팩트가 디자인 모델로 발전되었습니다.

탐색 맵, 사용자 인터페이스 프로토타입

사용자 인터페이스가 크고 복잡한 프로젝트의 경우 사용자 인터페이스 디자인을 고려해야 합니다.

선택사항

덜 형식적인 사용자 인터페이스는 더 작은 개발 조건에 적합할 수 있습니다.

디자인 모델

소규모 시스템을 포함한 대부분의 시스템에서 디자인 오류로 인한 고가의 재작업을 방지하려면 구현 전에 디자인을 수행해야 합니다. 비주얼 모델링을 사용하면 디자인을 쉽게 통신할 수 있습니다. 포워드 엔지니어링 및 리버스 엔지니어링에 대한 도구를 사용하면 구현 모델의 일관성을 보장하고 노력을 절감할 수 있습니다.

대부분의 프로젝트에서 권장됩니다.

소규모 프로젝트의 경우 자동 도구의 사용은 중요하지는 않지만 장기적인 생산성 이점을 가질 수 있습니다.

디자인 클래스, 디자인 패키지

클래스 및 패키지는 객체 지향 디자인의 기본 파트입니다. 객체 지향 디자인은 대부분의 프로젝트에서 사용하는 표준 디자인 접근 방식입니다.

대부분의 프로젝트에서 권장됩니다.

기본 사용자 조정 문제에서는 사용할 스테레오타입을 결정합니다(디자인 가이드라인에서 캡처할 수 있음).

유스 케이스 실현(realization)

유스 케이스에서 디자인까지의 브릿지를 제공합니다.

대부분의 프로젝트에서 권장됩니다.

인터페이스

일반적으로 인터페이스는 동작을 실현하는 세분화되지 않은 컴포넌트와는 별개로 동작을 정의하는 데 사용됩니다.

대부분의 프로젝트에서 권장됩니다.

컴포넌트 기반 디자인이 표준 디자인 접근 방식입니다.

디자인 서브시스템

디자인 서브시스템은 인터페이스를 제공하는 컴포넌트 내부의 동작을 캡슐화하는 데 사용됩니다. 클래스 및/또는 기타 서브시스템의 상호작용을 캡슐화하는 데 사용됩니다.

대부분의 프로젝트에서 권장됩니다.

서브시스템은 종종 디자인 추상 레벨을 높이는 데 유용합니다. 그러면 시스템을 이해하기 쉬워집니다.

이벤트

많은 외부 이벤트에 응답하는 시스템에 유용할 수 있습니다. 실시간 시스템에서 권장사항입니다.

프로토콜

실시간 시스템에서 필수사항입니다. 실시간 시스템에서 권장사항입니다.

신호

동시성이 요구되고 이벤트에 기반하는 시스템에 유용할 수 있습니다.

실시간 시스템에서 필수사항입니다.

동시성이 요구되고 이벤트에 기반하는 시스템에 유용할 수 있습니다.

실시간 시스템에서 권장사항입니다.

캡슐

실시간 시스템에서 동시성 정도가 높은 시스템을 모델링 및 디자인하는 경우 유용할 수 있습니다.

실시간 시스템에서 권장사항입니다.

데이터 모델 지속적 정보의 논리 및 가능한 실제 구조를 설명하는 데 사용됩니다.

데이터베이스를 사용하는 프로젝트에서 권장사항입니다.

배치 모델 런타임에서 처리 노드의 구성, 해당 노드 간 통신 링크 및 해당 노드에 상주하는 컴포넌트 인스턴스와 오브젝트를 표시합니다.

선택사항입니다.

많은 시스템에는 처리 노드가 여러 개 있으므로 배치 모델을 처리해야 합니다. 그러나 소프트웨어 아키텍처 문서의 섹션으로 캡처될 수 있으므로 별도로 식별된 아티팩트로 존재하지 않아도 됩니다.

아키텍처 개념 검증 아키텍처 측면에서 중요한 요구사항을 충족시키는 솔루션이 있는지 여부를 판별하는 데 사용됩니다. 대부분의 프로젝트에서 권장됩니다.

많은 프로젝트가 아키텍처 개념 검증을 사용하여 요구사항의 실현 가능성을 판별합니다. 많은 양식을 사용할 수 있습니다. 예를 들어 다음과 같습니다.

  • 솔루션에 적합해 보이는 알려진 기술 목록
  • 솔루션의 개념 모델 개요
  • 솔루션의 시뮬레이션
  • 실행 가능 프로토타입
참조 아키텍처 참조 아키텍처는 개발 속도를 높이고 입증된 솔루션을 재사용하여 위험성을 줄입니다.

대부분의 프로젝트에서 권장됩니다.

적합한 참조 아키텍처 자료가 있는 경우 개발 속도를 크게 높이고 위험성을 크게 줄일 수 있습니다.

소프트웨어 아키텍처 문서(SAD) 소프트웨어 아키텍처 문서는 시스템의 포괄적인 아키텍처 개요를 제공하는 데 사용됩니다. 이 개요는 시스템을 이해하고 주요 아키텍처 결정을 캡처하는 데 도움이 됩니다.

대부분의 프로젝트에서 권장됩니다.

소프트웨어 아키텍처의 상위 레벨 개요는 가장 소규모의 시스템을 제외한 모든 시스템에서 유용합니다. 일반적으로 복잡한 시스템에는 소규모 프로젝트보다 더 많은 보기와 더 자세한 내용이 필요합니다.

사용자 인터페이스 프로토타입 실제 개발을 시작하기 전에 기능 및 사용성을 표현하고 테스트하는 데 사용됩니다. 너무 많은 시간을 소모하기 전에 디자인의 유효성을 검증하는 효과적인 방법입니다.

대부분의 프로젝트에서 권장됩니다.



사용할 보고서 결정

사용할 보고서 결정은 프로젝트에서 사용 가능한 보고 도구에 따라 다릅니다. 보고서 생성 도구가 있는 경우 모델 지향 중간 산출물(예: 디자인 클래스, 유스 케이스 실현(realization))에서 보고서를 생성하는 것이 좋습니다. RUP 구성의 기존 보고서는 중간 산출물 설명 페이지에서 사용 가능하거나 트리 브라우저의 관련 중간 산출물 아래에 그룹화되어 있습니다.

검토 방법 결정

사용할 각 중간 산출물에 사용될 검토 레벨을 결정하십시오.  특히 분석 및 디자인의 결과를 검토하고 승인하는 방법 및 결과 검토 범위를 결정하십시오.   

다음은 분석 및 디자인 중 검토 수행의 장점입니다.

  • 테스트에서 발견할 수 없거나 발견하기 어려운 문제점을 발견합니다. 예를 들어 스타일 및 레이아웃의 문제점이 이에 해당합니다.  
  • 공통 모델링 스타일 및 개인이 서로에게서 학습할 기회를 강화하는 방법입니다.  
  • 테스트 중 프로젝트 후반에서야 발견이 되는 결함을 발견합니다.

다음은 분석 및 디자인 중 검토의 단점입니다.

  • 시간 및 자원이 소모됩니다.  
  • 올바르게 관리하지 않으면 잘못 사용하기 쉽습니다.

분석 및 디자인 검토에 대해 바꿀 수 있는 요소는 검토 방법, 자원 및 범위입니다. 다음은 프로젝트에서 수행하도록 결정할 수 있는 작업에 대한 몇 가지 예제입니다.

  • 검수를 수행하고 서면으로 결과를 제공하는 하나의 피어만 서브시스템의 로컬 변경사항을 검토하도록 결정합니다.
  • 검토하지 않을 디자인 파트를 결정합니다. 예를 들어 프로젝트의 각 구성원에 대한 일부 클래스만 검토하고 나머지 결과에서도 스타일 품질이 유사할 것이라고 예상합니다.
  • 별도의 회의에서 고객이 소프트웨어 아키텍처 문서를 검토하도록 결정합니다.
  • 중요한 인터페이스, 즉, 여러 프로젝트 구성원의 작업에 영향을 주는 인터페이스를 변경하는 경우 정규 검토 회의를 여십시오.

검토 레벨에 대한 자세한 정보는 가이드라인: 검토 레벨을 참조하십시오. 

코드 생성 여부 결정

디자인 모델에서 코드를 생성하는지 여부에 따라 디자인 방법이 달라집니다. 코드를 생성하는 경우 디자인은 매우 자세해야 합니다. 반면 디자인에서 코드를 생성하지 않는 경우 디자인이 매우 자세할 필요는 없습니다. 반대로, 디자인의 세부사항은 코드와 수동으로 동기화되어야 합니다.