개발 프로세스에서 모델 사용
Visual Studio에서 모델을 사용하여 시스템, 애플리케이션 또는 구성 요소를 이해하고 변경할 수 있습니다. 모델은 시스템이 작동하는 세계를 시각화하고, 사용자 요구를 명확하게 설명하고, 시스템 아키텍처를 정의하고, 코드를 분석하고, 코드가 요구 사항을 충족하는지 확인하는 데 도움이 됩니다.
각 모델 형식을 지원하는 Visual Studio 버전을 확인하려면 Version support for architecture and modeling tools를 참조하세요.
모델은 다음과 같은 여러 방식에서 유용할 수 있습니다.
모델링 다이어그램을 그리면 요구 사항, 아키텍처 및 전반적인 디자인에 관련된 개념을 명확하게 설명할 수 있습니다. 자세한 내용은 사용자 요구 사항 모델링을 참조하세요.
모델로 작업하면 요구 사항 불일치를 노출할 수 있습니다.
모델을 사용하여 커뮤니케이션하면 중요한 개념을 자연어보다 더 명확하게 전달할 수 있습니다. 자세한 내용은 앱 아키텍처 모델링을 참조하세요.
때로는 모델을 사용하여 코드 또는 데이터베이스 스키마나 문서와 같은 기타 아티팩트를 생성할 수 있습니다. 예를 들어 Visual Studio의 모델링 구성 요소는 모델에서 생성됩니다. 자세한 내용은 모델에서 앱 생성 및 구성을 참조하세요.
매우 민첩한 프로세스부터 격식 있는 프로세스에 이르기까지 다양한 프로세스에 모델을 사용할 수 있습니다.
모델을 사용하여 모호성 줄이기
모델링 언어는 자연어보다 명확하므로 일반적으로 소프트웨어 개발 중에 필요한 아이디어를 표현하는 데 사용됩니다.
프로젝트에 민첩한 방식을 따르는 소규모 팀이 있는 경우 모델을 사용하여 사용자 스토리를 명확하게 설명할 수 있습니다. 고객과 요구에 대해 논의할 때 모델을 만들면 스파이크 또는 프로토타입 코드를 작성하는 것보다 훨씬 더 빠르게 보다 광범위한 제품 영역에 걸쳐 유용한 질문을 생성할 수 있습니다.
프로젝트가 대규모이고 전 세계 여러 지역에 팀이 있는 경우 모델을 사용하여 일반 텍스트보다 훨씬 더 효과적으로 요구 사항 및 아키텍처를 전달할 수 있습니다.
두 경우 모두, 모델을 만들면 거의 항상 불일치와 모호성이 상당히 감소합니다. 이해 관계자에 따라 시스템이 작동하는 비즈니스 세계에 대한 이해가 다른 경우가 많으며, 개발자마다 시스템 작동 방식에 대한 이해가 서로 다릅니다. 일반적으로 논의의 초점으로 모델을 사용하면 이러한 차이가 노출됩니다. 모델을 사용하여 불일치를 줄이는 방법에 대한 자세한 내용은 사용자 요구 사항 모델링을 참조하세요.
다른 아티팩트와 함께 모델 사용
모델 자체는 요구 사항 사양 또는 아키텍처가 아닙니다. 이러한 사항의 일부 측면을 보다 명확하게 표현하기 위한 도구지만 소프트웨어 디자인 중에 필요한 모든 개념을 표현할 수 있는 것은 아닙니다. OneNote 페이지 또는 단락, Microsoft Office 문서, Team Foundation의 작업 항목 또는 프로젝트 사무실 벽의 스티커 메모와 같은 다른 커뮤니케이션 수단과 함께 사용해야 합니다. 마지막 항목을 제외하고 이러한 모든 개체 형식을 모델의 요소 파트에 연결할 수 있습니다.
일반적으로 모델과 함께 사용되는 사양의 다른 측면은 다음과 같습니다. 프로젝트의 크기 및 스타일에 따라 이러한 측면 중 일부를 사용하거나 전혀 사용하지 않을 수 있습니다.
사용자 스토리. 사용자 스토리는 프로젝트 반복 중 하나에서 전달되는 시스템 동작 측면에 대한 간단한 설명으로, 사용자 및 다른 이해 관계자와 함께 논의됩니다. 일반적인 사용자 스토리는 “고객이 다음을 수행할 수 있습니다...”로 시작됩니다. 사용자 스토리는 사용 사례 그룹을 소개하거나 이전에 개발된 사용 사례의 확장을 정의할 수 있습니다. 사용 사례를 정의하거나 확장하면 사용자 스토리를 보다 명확하게 설명하는 데 도움이 됩니다.
변경 요청. 보다 공식적인 프로젝트의 변경 요청은 민첩한 프로젝트의 사용자 스토리와 매우 비슷합니다. 민첩한 접근 방식은 모든 요구 사항을 이전 반복에서 개발된 사항에 대한 변경 내용으로 처리합니다.
사용 사례 설명. 사용 사례는 특정 목표를 달성하기 위해 사용자가 시스템을 조작하는 한 가지 방법을 나타냅니다. 자세한 설명에는 목표, 기본 및 대체 이벤트 시퀀스 및 예외적 결과가 포함됩니다. 사용 사례 다이어그램은 사용 사례를 요약하고 개요를 제공하는 데 도움이 됩니다.
시나리오. 시나리오는 시스템, 사용자 및 기타 시스템이 함께 작동하여 이해 관계자에게 가치를 제공하는 방식을 표시하는 이벤트 시퀀스에 대한 자세한 설명입니다. 사용자 인터페이스의 슬라이드 쇼 또는 사용자 인터페이스의 프로토타입 형식을 사용할 수 있습니다. 하나의 사용 사례 또는 사용 사례 시퀀스를 설명할 수 있습니다.
용어집. 프로젝트의 요구 사항 용어집은 고객이 세계를 논의할 때 사용하는 단어를 설명합니다. 사용자 인터페이스 및 요구 사항 모델도 이러한 용어를 사용해야 합니다. 클래스 다이어그램은 이러한 용어 간의 관계를 명확하게 설명하는 데 도움이 됩니다. 다이어그램과 용어집을 만들면 사용자와 개발자 간의 오해가 감소할 뿐 아니라 여러 비즈니스 이해 관계자 간의 오해가 대체로 노출됩니다.
비즈니스 규칙. 대부분의 비즈니스 규칙은 요구 사항 클래스 모델의 연결 및 특성에 대한 고정 제약 조건 및 시퀀스 다이어그램의 제약 조건으로 표현될 수 있습니다.
전반적인 디자인. 주요 파트 및 해당 파트의 연동 방식에 대해 설명합니다. 구성 요소, 시퀀스 및 인터페이스 다이어그램이 전반적인 디자인의 주요 파트입니다.
디자인 패턴. 시스템의 여러 파트에서 공유되는 디자인 규칙에 대해 설명합니다.
테스트 사양. 테스트 스크립트 및 테스트 코드 디자인은 동작 및 시퀀스 다이어그램을 사용하여 테스트 단계 시퀀스를 설명할 수 있습니다. 시스템 테스트는 요구 사항 변경 시 쉽게 변경할 수 있도록 요구 사항 모델 측면에서 표현해야 합니다.
프로젝트 계획. 프로젝트 계획 또는 백로그는 각 기능이 전달되는 시기를 정의합니다. 구현하거나 확장하는 사용 사례 및 비즈니스 규칙을 지정하여 각 기능을 정의할 수 있습니다. 계획에서 직접 사용 사례 및 비즈니스 규칙을 참조하거나, 별도 문서에서 기능 집합을 정의하고 계획에 기능 제목을 사용할 수 있습니다.
반복 계획에서 모델 사용
모든 프로젝트는 크기 및 구성이 다르지만, 일반 프로젝트는 2주에서 6주에 걸친 일련의 반복으로 계획됩니다. 초기 반복의 피드백을 사용하여 이후 반복의 범위와 계획을 조정할 수 있도록 충분한 반복을 계획하는 것이 중요합니다.
다음 제안 사항은 반복적인 프로젝트에서 모델링의 혜택을 인식하는 데 유용할 수 있습니다.
각 반복이 임박하면 포커스 구체화
각 반복이 임박하면 모델을 사용하여 반복이 끝날 때 전달되는 사항을 정의합니다.
초기 반복에서 모든 사항을 자세히 모델링하지 마세요. 첫 번째 반복에서는 사용자 용어집의 주요 항목에 대한 클래스 다이어그램을 만들고, 주요 사용 사례 다이어그램을 그리고, 주요 구성 요소 다이어그램을 그립니다. 세부 정보는 프로젝트의 이후 단계에서 변경되므로 이러한 사항을 자세히 설명하지 마세요. 이 모델에서 정의된 용어를 사용하여 기능 또는 주요 사용자 스토리의 목록을 만듭니다. 프로젝트 전반에 걸쳐 예상 작업의 대략적인 균형을 맞추기 위해 반복에 기능을 할당합니다. 이러한 할당은 프로젝트의 이후 단계에서 변경됩니다.
초기 반복에서는 가장 중요한 사용 사례의 간소화된 버전을 구현합니다. 이후 반복에서 이러한 사용 사례를 확장합니다. 이 접근 방식은 요구 사항 또는 아키텍처의 결함이 프로젝트에서 너무 늦게 발견되어 조치를 취할 수 없는 위험을 줄이는 데 도움이 됩니다.
각 반복이 거의 끝나면 요구 사항 워크숍을 열어 다음 반복에서 개발할 요구 사항 또는 사용자 스토리를 자세히 정의합니다. 개발자와 시스템 테스터뿐 아니라 우선 순위를 결정할 수 있는 사용자 및 비즈니스 이해 관계자도 초대합니다. 2주 반복에 대한 요구 사항을 정의하는 데 3시간을 할애합니다.
워크숍의 목표는 다음 반복이 끝날 때까지 달성할 목표에 대해 모두가 동의하는 것입니다. 모델을 도구 중 하나로 사용하여 요구 사항을 명확하게 설명합니다. 워크숍의 결과는 반복 백로그, 즉 Team Foundation의 개발 작업 목록 및 Microsoft Test Manager의 테스트 도구 모음입니다.
요구 사항 워크숍에서는 예상 개발 작업을 결정해야 하는 경우에만 디자인을 논의합니다. 그렇지 않으면 사용자가 직접 경험할 수 있는 시스템 동작만 논의합니다. 요구 사항 모델을 아키텍처 모델과 별도로 유지합니다.
일반적으로 비전문적 이해 관계자도 약간의 도움만 받으면 UML 다이어그램을 문제 없이 이해할 수 있습니다.
작업 항목에 모델 연결
요구 사항 워크숍 후에 요구 사항 모델을 자세히 설명하고 개발 작업에 모델을 연결합니다. Team Foundation의 작업 항목을 모델의 요소에 연결하여 이 작업을 수행할 수 있습니다.
작업 항목에 모든 요소를 연결할 수 있지만 가장 유용한 요소는 다음과 같습니다.
- 비즈니스 규칙 또는 서비스 품질 요구 사항을 설명하는 주석. 자세한 내용은 사용자 요구 사항 모델링을 참조하세요.
테스트에 모델 연결
요구 사항 모델을 사용하여 수락 테스트의 디자인 과정을 안내합니다. 개발 작업과 동시에 이러한 테스트를 만듭니다.
이 기술에 대한 자세한 내용은 모델에서 테스트 개발을 참조하세요.
남은 작업 예상
요구 사항 모델은 각 반복의 크기를 기준으로 프로젝트의 전체 크기를 예상하는 데 도움이 됩니다. 사용 사례 및 클래스의 개수와 복잡성을 평가하면 필요한 개발 작업을 예상할 수 있습니다. 처음 몇 개의 반복을 완료했을 때 처리된 요구 사항과 처리해야 할 요구 사항을 비교하면 나머지 프로젝트의 비용과 범위를 대략 측정할 수 있습니다.
각 반복이 거의 끝나면 이후 반복에 대한 요구 사항 할당을 검토합니다. 각 반복이 끝날 때 소프트웨어 상태를 사용 사례 다이어그램에 하위 시스템으로 나타내면 유용할 수 있습니다. 논의에서 이러한 하위 시스템 간에 사용 사례 및 사용 사례 확장을 이동할 수 있습니다.
추상화 수준
모델에는 소프트웨어와 관련해서 다양한 추상화가 있습니다. 가장 구체적인 모델은 프로그램 코드를 직접 나타내고, 가장 추상적인 모델은 코드로 표현될 수도 있고 표현되지 않을 수도 있는 비즈니스 개념을 나타냅니다.
여러 종류의 다이어그램을 통해 모델을 볼 수 있습니다. 모델 및 다이어그램에 대한 자세한 내용은 앱용 모델 만들기를 참조하세요.
각 종류의 다이어그램은 서로 다른 추상화 수준에서 디자인을 설명하는 데 유용합니다. 대부분의 다이어그램 형식은 두 개 이상의 수준에서 유용합니다. 이 표에서는 각 다이어그램 형식을 사용할 수 있는 방법을 보여 줍니다.
| 디자인 수준 | 다이어그램 형식 |
|---|---|
| 비즈니스 프로세스 시스템이 사용되는 컨텍스트를 이해하면 사용자가 시스템에서 요구하는 사항을 이해하는 데 도움이 됩니다. |
- 개념적 클래스 다이어그램은 비즈니스 프로세스 내에서 사용되는 비즈니스 개념을 설명합니다. |
| 사용자 요구 사항 사용자가 시스템에서 요구하는 사항의 정의입니다. |
- 비즈니스 규칙 및 서비스 품질 요구 사항은 별도 문서에서 설명할 수 있습니다. |
| 개략적인 디자인 시스템의 전체 구조: 주요 구성 요소 및 결합 방식입니다. |
- 종속성 다이어그램은 시스템이 상호 종속적인 파트로 구성된 방식을 설명합니다. 종속성 다이어그램에 대해 프로그램 코드의 유효성을 검사하여 아키텍처를 준수하는지 확인할 수 있습니다. |
| 코드 분석 코드에서 다이어그램을 생성할 수 있습니다. |
- 종속성 다이어그램은 클래스 간의 종속성을 표시합니다. 종속성 다이어그램에 대해 업데이트된 코드의 유효성을 검사할 수 있습니다. - 클래스 다이어그램은 코드의 클래스를 보여 줍니다. |
External resources
관련 콘텐츠
참고 항목
텍스트 템플릿 변환 구성 요소는 Visual Studio 확장 개발 워크로드의 일부로 자동으로 설치됩니다. Visual Studio 설치 프로그램의 개별 구성 요소 탭, SDK, 라이브러리, 프레임워크 범주 아래에서 설치할 수도 있습니다. 개별 구성 요소 탭에서 Modeling SDK 구성 요소를 설치합니다.