가이드라인:
|
워크플로우 파트 |
설명 |
---|---|
사용자 인터페이스 설계 | 일부 프로젝트에서는 사용자 인터페이스를 설계하지 않기로 결정합니다. 한 가지 이유는 사용자 인터페이스가 개발하기 쉽다는 것일 수 있습니다. 사용자 인터페이스를 설계하지 않기로 결정할 경우 이는 탐색 맵 및 사용자 인터페이스 프로토타입을 개발하지 않음을 의미하는 것입니다. |
데이터베이스 설계 | 엔티티를 데이터베이스에 저장할 경우에만 사용합니다. 데이터베이스를 설계하지 않기로 결정할 경우 이는 데이터 모델을 개발하지 않음을 의미하는 것입니다. |
프로젝트 특정 프로세스의 일부분으로서 결정사항을 문서화하십시오.
사용할 결과물과 각 결과물의 사용 방법을 결정하십시오. 아래의 테이블은 필수 결과물과 특정 케이스에서만 사용되는 해당 결과물을 설명합니다. 각 결과물 조정 방법에 대한 자세한 정보와 해당 특정 결과물의 장점 및 단점에 대한 설명은 각 결과물의 "조정" 섹션을 읽으십시오.
결과물마다 결과물을 사용해야 하는 방법(필수, 필요, 가능 또는 금지)을 결정하십시오.
결과물 | 목적 |
조정(선택사항, 권장사항) |
---|---|---|
분석 모델(분석 클래스) | 분석 모델은 설계 결정 전의 요구사항을 더 잘 이해하는 데 유용합니다. 복합 시스템에서 시스템의 개념적 개요를 제공하도록 분석 클래스를 유지관리할 수 있습니다. |
선택사항 다수의 프로젝트에서 초기 설계 모델은 분석 모델 대신 사용됩니다. 분석 모델을 작성하는 프로젝트에서 분석 모델은 일반적으로 설계 모델로 전개되는 임시 결과물입니다. |
크고 복잡한 사용자 인터페이스가 있는 프로젝트에서 사용자 인터페이스 설계를 고려해야 합니다. |
선택사항 비공식적인 사용자 인터페이스 설계일수록 개발 노력을 더 적게 들일 수 있습니다. |
|
설계 모델 |
대부분의 시스템, 비록 상대적으로 작은 시스템이라도 설계 오류로 인한 재작업으로 비용 손실이 발생하지 않도록 구현 전에 반드시 설계를 수행해야 합니다. 비주얼 모델을 사용하면 설계 내용을 쉽게 전달할 수 있습니다. 포워드 엔지니어링 및 리버스 엔지니어링용 툴은 구현 모델과의 일관성을 보장하고 노력을 줄일 수 있습니다. |
대부분의 프로젝트에 권장합니다. 소형 프로젝트에서 자동화된 툴의 사용은 중요하지 않지만 장기적인 생산성에는 도움이 될 수 있습니다. |
|
클래스 및 패키지는 객체 지향 설계의 기본 파트입니다. 객체 지향 설계는 대부분의 프로젝트에서 사용되는 표준 설계 접근 방법입니다. |
대부분의 프로젝트에 권장합니다. 기본 조정 문제에서 사용할 스테레오타입(이는 설계 가이드라인에서 캡처할 수 있음)을 결정합니다. |
|
유스 케이스에서 설계로 브릿지를 제공하십시오. |
대부분의 프로젝트에 권장합니다. |
|
인터페이스는 일반적으로 작동을 인식하는 큰 입자의 컴포넌트와 상관 없이 작동을 정의하는 데 사용됩니다. |
대부분의 프로젝트에 권장합니다. 컴포넌트 기반 설계는 표준 설계 접근 방법이 됩니다. |
|
설계 서브시스템은 인터페이스를 제공하는 컴포넌트 내부에서 작동을 캡슐화하는 데 사용됩니다. 클래스 및/또는 기타 서브시스템의 상호 작용을 캡슐화하는 데 사용됩니다. |
대부분의 프로젝트에 권장합니다. 서브시스템은 종종 설계 추상화의 레벨을 높이는 데 유용합니다. 서브시스템을 통해 시스템을 보다 쉽게 이해할 수 있습니다. |
|
다수의 외부 이벤트에 응답하는 시스템에 유용할 수 있습니다. | |
|
동시성이 필요한 이벤트 기반 시스템에 유용할 수 있습니다. |
실시간 시스템에 권장합니다. 동시성이 필요한 이벤트 기반 시스템에 유용할 수 있습니다. |
데이터 모델 | 논리적이고도 거의 실제적인 지속적 정보 구조를 설명하는 데 사용합니다. |
데이터베이스를 사용하는 프로젝트에 권장합니다. |
전개 모델 | 런타임시 처리 노드의 형상, 노드 간 의사소통 링크 및 노드에 있는 컴포넌트 인스턴스와 객체를 표시합니다. |
선택사항. 다수의 시스템이 복수 처리 노드를 보유하므로 전개 모델을 어드레스해야 합니다. 그러나 SAD(Software Architecture Document)의 섹션으로 전개 모델을 캡처할 수 있으므로 별도로 식별된 결과물로서 존재할 필요가 없습니다. |
구조적 개념 증명 방식 | 구조적으로 중요한 요구사항을 충족시키는 솔루션이 존재하는지 여부를 판별하는 데 사용합니다. | 대부분의 프로젝트에 권장합니다.
다수의 프로젝트는 요구사항의 실행 가능성을 판별하는 데 POC 방식을 사용합니다. 이는 여러 형식을 취할 수 있으며 예를 들면 다음과 같습니다.
|
참조 구조 | 참조 구조는 입증된 솔루션을 재사용하여 개발 속도를 높이고 위험을 줄입니다. |
대부분의 프로젝트에 권장합니다. 적절한 참조 구조 자료가 존재할 경우 개발 속도를 상당히 높일 수 있으며 위험도 줄일 수 있습니다. |
SAD(Software Architecture Document) | SAD(Software Architecture Document)는 시스템에 대한 포괄적인 구조적 개요를 제공하는 데 사용됩니다. 이 개요는 시스템을 이해하고 핵심 구조적 결정사항을 캡처하는 데 도움이 됩니다. |
대부분의 프로젝트에 권장합니다. 소프트웨어 구조의 상위 레벨 개요는 가장 작은 시스템을 제외한 모든 시스템에서 유용합니다. 복합 시스템에서는 일반적으로 소형 프로젝트보다 상위 레벨의 세부사항 및 수 많은 보기가 필요합니다. |
사용자 인터페이스 프로토타입 | 실제 개발이 시작되기 전에 기능성 및 사용성을 표시하고 테스트하는 데 사용합니다. 시간 낭비적인 요인이 발생하기 전에 설계의 유효성을 확인하는 효과적인 수단입니다. |
대부분의 프로젝트에 권장합니다. |
각 결과물을 조정하여 프로젝트의 요구에 맞추십시오. 조정 고려사항은 결과물 설명 페이지의 조정 섹션
사용할 보고서는 프로젝트에 사용 가능한 보고 툴에 따라 결정합니다. 보고서 생성 툴을 사용할 수 있는 경우 설계 클래스, 유스 케이스 실현과 같은 모델 지향 결과물의 보고서를 생성하는 것이 좋습니다. RUP 형상에서 기존 보고서는 결과물 설명 페이지로부터 사용 가능하거나 트리 브라우저의 관련 결과물 아래에 그룹화되어 있습니다.
결과물마다 검토 레벨을 결정하고 분석 및 설계 결과의 검토 및 승인 방법과 결과를 검토할 범위를 결정하십시오.
설계 검토의 장점은 다음과 같습니다.
설계 검토의 단점은 다음과 같습니다.
변경될 수 있는 요소는 검토 기술, 자원 및 범위입니다. 다음은 프로젝트에서 수행하기로 결정할 수 있는 사항에 대한 몇 가지 예입니다.
검토 및 다른 종류의 검토에 대한 자세한 정보는 작업 가이드라인: 검토를
참조하십시오.
설계 수행 방식은 설계 모델에서 코드를 생성할 것인지 여부에 따라 다릅니다. 코드를 생성할 경우 설계를 상당히 상세하게 수행해야 합니다. 한편, 설계에서 코드를 생성하지 않을 경우 설계를 상세하게 수행할 필요는 거의 없습니다. 반대로 설계에서 세부사항은 코드와 직접 동기화되어야 합니다.
Rational Unified Process
|