개발 프로세스에서 모델 사용

Visual Studio Ultimate에서는 모델을 사용하여 시스템, 응용 프로그램 또는 구성 요소를 이해하고 변경할 수 있습니다. 모델을 사용하면 시스템 동작 환경 시각화, 사용자 요구 명시화, 시스템 아키텍처 정의, 코드 분석, 요구 사항을 충족하는 코드 작성 등의 작업을 수행하는 데 도움이 됩니다.

비디오 소개는 Video: UML with Visual Studio 2010을 참조하십시오.

모델을 사용하는 방법

다음과 같은 방식으로 모델을 사용할 수 있습니다.

• 모델링 다이어그램을 그리면 요구 사항, 아키텍처 및 고급 디자인과 관련된 개념을 명확하게 할 수 있습니다. 자세한 내용은 사용자 요구 사항 모델링을 참조하십시오.

• 모델을 사용하면 요구 사항의 불일치를 나타낼 수 있습니다.

• 모델을 사용하면 중요한 개념을 전달할 때 자연어를 사용하는 경우보다 모호성을 줄일 수 있습니다. 자세한 내용은 소프트웨어 시스템의 아키텍처 모델링을 참조하십시오.

• 경우에 따라 모델을 사용하여 코드 또는 기타 아티팩트(예: 데이터베이스 스키마 또는 문서)를 생성할 수 있습니다. 예를 들어 Visual Studio Ultimate의 모델링 구성 요소는 모델에서 생성됩니다. 자세한 내용은 모델에서 응용 프로그램 생성 및 구성을 참조하십시오.

Extreme Agile에서 High Ceremony까지 다양한 프로세스에서 모델을 사용할 수 있습니다.

모호성을 줄이기 위해 모델 사용

모델링 언어는 자연어보다 명확하며 소프트웨어 개발 중에 일반적으로 필요한 개념을 표현하도록 되어 있습니다.

프로젝트에 agile 규칙을 따르는 소규모 팀이 있는 경우 모델을 사용하면 사용자 스토리를 명확하게 할 수 있습니다. 고객과 요구 사항에 대해 논의할 때 모델을 만들면 스파이크 또는 프로토타입 코드를 작성하는 것보다 더 빨리 그리고 제품 영역의 범위를 넓혀 유용한 질문을 만들 수 있습니다.

프로젝트의 규모가 크고 다양한 분야의 팀을 포함하는 경우 모델을 사용하면 일반 텍스트를 사용하는 것보다 훨씬 효과적으로 요구 사항 및 아키텍처를 전달할 수 있습니다.

두 경우 모두 모델을 만들면 거의 항상 불일치 및 모호성 문제가 상당히 줄어듭니다. 각 관련자마다 시스템이 동작하는 비즈니스 환경을 서로 다르게 이해하고 각 개발자마다 시스템이 동작하는 방식을 서로 다르게 이해하는 경우가 종종 있습니다. 모델을 논의의 중심으로 사용하면 대개 이러한 차이점이 노출됩니다. 모델을 사용하여 불일치를 줄이는 방법에 대한 자세한 내용은 사용자 요구 사항 모델링을 참조하십시오.

다른 아티팩트와 함께 모델 사용

모델 자체는 요구 사항 사양 또는 아키텍처가 아닙니다. 모델은 이러한 디자인 측면을 명확하게 표현하기 위한 도구입니다. 그러나 소프트웨어를 디자인하는 동안 필요한 모든 개념을 표현할 수는 없습니다. 따라서 OneNote 페이지나 단락, Microsoft Office 문서, Team Foundation의 작업 항목 또는 프로젝트 회의실 벽의 스티커 메모와 같은 다른 통신 수단과 모델을 함께 사용해야 합니다. 스티커 메모를 제외하고 이러한 모든 개체 형식을 모델의 요소 부분에 연결할 수 있습니다.

일반적으로 사양에서 모델과 함께 사용되는 다른 요소는 다음과 같습니다. 프로젝트의 규모와 스타일에 따라 이러한 요소 중 일부를 사용하거나 전혀 사용하지 않을 수 있습니다.

• 사용자 스토리. 사용자 스토리는 프로젝트 반복 중 하나에 전달되는 시스템 동작 요소에 대해 사용자 및 다른 관련자와 논의된 간단한 설명입니다. 일반적으로 사용자 스토리에는 "고객은 다음과 같은 작업을 수행할 수 있습니다." 라는 내용이 포함됩니다. 사용자 스토리는 사용 사례 그룹을 소개하거나, 이전에 개발된 사용 사례의 확장을 정의할 수 있습니다. 사용 사례를 정의하거나 확장하면 사용자 스토리를 더 명확하게 지정할 수 있습니다.

• 변경 요청. 공식적인 프로젝트의 변경 요청은 agile 프로젝트의 사용자 스토리와 매우 비슷합니다. agile 방법은 모든 요구 사항을 이전 반복에서 개발한 것에 대한 변경으로 간주합니다.

• 사용 사례 설명. 사용 사례는 사용자가 특정 목표를 달성하기 위해 시스템과 상호 작용하는 방식을 나타냅니다. 전체 설명에는 목표, 기본 및 대체 이벤트 시퀀스, 예외적 결과 등이 포함됩니다. 사용 사례 다이어그램을 사용하면 사용 사례를 요약하고 개요를 제공할 수 있습니다.

• 시나리오. 시나리오는 이벤트 시퀀스를 매우 자세하게 기술하는 것으로, 관련자에게 유용성을 제공하기 위해 시스템, 사용자 및 다른 시스템이 함께 동작하는 방식을 보여 줍니다. 이때 사용자 인터페이스의 슬라이드 쇼 또는 프로토타입 형태로 제공될 수 있습니다. 시나리오는 하나의 사용 사례 또는 사용 사례 시퀀스를 나타낼 수 있습니다.

• 용어. 프로젝트의 요구 사항 용어는 고객이 비즈니스 환경을 논의하는 데 사용되는 단어를 기술합니다. 사용자 인터페이스 및 요구 사항 모델에서도 이러한 용어를 사용해야 합니다. 클래스 다이어그램을 사용하면 이러한 용어 간의 관계를 명확하게 할 수 있습니다. 다이어그램과 용어를 만들면 사용자와 개발자 사이의 오해를 줄일 수 있지만 비즈니스 관련자 사이에 오해를 일으킬 가능성이 매우 높습니다.

• 비즈니스 규칙. 대부분의 비즈니스 규칙은 시퀀스 다이어그램에서 제약 조건으로 표현하거나, 요구 사항 클래스 모델의 연결 및 특성에서 고정 제약 조건으로 표현할 수 있습니다.

• 고급 디자인. 주요 부분 및 부분이 서로 연결되는 방식을 기술합니다. 구성 요소, 시퀀스 및 인터페이스 다이어그램은 고급 디자인의 주요 부분입니다.

• 디자인 패턴. 시스템의 각 부분에서 공유되는 디자인 규칙을 기술합니다.

• 테스트 사양. 테스트 코드 디자인과 테스트 스크립트는 동작 다이어그램 및 시퀀스 다이어그램을 사용하여 테스트 단계의 시퀀스를 기술할 수 있습니다. 시스템 테스트는 요구 사항이 바뀌면 이에 따라 쉽게 변경할 수 있도록 요구 사항 모델 측면에서 표현되어야 합니다.

• 프로젝트 계획. 프로젝트 계획 또는 백로그는 각 기능이 제공되는 시기를 정의합니다. 구현하거나 확장할 사용 사례 및 비즈니스 규칙을 지정하여 각 기능을 정의할 수 있습니다. 사용 사례 및 비즈니스 규칙을 프로젝트 계획에서 직접 참조하거나, 기능 집합을 별도의 문서에 정의하여 기능 제목을 프로젝트 계획에 사용할 수 있습니다.

반복 계획에 모델 사용

모든 프로젝트는 규모 및 구성이 서로 다르지만 일반적인 프로젝트는 2~6주 사이의 일련의 반복으로 계획됩니다. 초기 반복의 피드백을 사용하여 이후 반복의 범위와 계획을 조정할 수 있도록 충분한 반복을 계획하는 것이 중요합니다.

반복적인 프로젝트에서 모델링할 때 이점을 구현하려면 다음과 같은 제안을 따르는 것이 좋습니다.

각 반복이 진행되면 세부 정보 지정

각 반복을 차례로 진행하는 동안 모델을 사용하여 반복이 끝날 때 제공될 요소를 정의할 수 있습니다.

• 초기 반복에서 모든 것을 상세히 모델링하지 마십시오. 첫 번째 반복에서는 사용자 용어의 주요 항목에 대한 클래스 다이어그램을 만들고, 주요 사용 사례 및 주요 구성 요소에 대한 다이어그램을 각각 그립니다. 프로젝트 후반에 세부 정보가 변경되므로 이러한 항목을 너무 자세히 기술하지 않는 것이 좋습니다. 이 모델에 정의된 용어를 사용하여 기능 또는 주요 사용자 스토리 목록을 만듭니다. 또한 프로젝트 전체에서 예상 작업량의 균형을 맞추기 위해 반복에 기능을 할당합니다. 이러한 할당은 프로젝트 후반에 변경됩니다.

• 초기 반복에서는 가장 중요한 모든 사용 사례를 간단한 버전으로 구현하십시오. 이러한 사용 사례를 이후 반복에서 확장합니다. 이 방법을 사용하면 요구 사항이나 아키텍처의 결함을 프로젝트에서 너무 늦게 발견하여 이에 대해 아무 대처도 할 수 없는 문제를 줄일 수 있습니다.

• 각 반복이 거의 끝나는 시점에서 요구 사항 워크숍을 주최하여 다음 반복에서 개발할 요구 사항 또는 사용자 스토리를 상세히 정의하십시오. 이때 개발자와 시스템 테스터는 물론 우선 순위를 결정할 수 있는 비즈니스 관련자와 사용자를 초대합니다. 2주 반복을 위한 요구 사항을 정의하는 데 3시간을 허용하십시오.

• 워크숍의 목적은 다음 반복이 끝날 때 달성되어야 할 임무에 대해 모든 사람들이 동의하도록 하는 것입니다. 모델을 하나의 도구로 사용하여 요구 사항을 명확히 지정하십시오. 워크숍의 결과는 반복 백로그, 즉 Team Foundation의 개발 작업 목록 및 Microsoft Test Manager의 테스트 도구 모음입니다.

• 요구 사항 워크숍에서는 개발 작업을 평가해야 할 경우에만 디자인에 대해 논의하십시오. 그렇지 않은 경우에는 사용자가 직접 경험할 수 있는 시스템 동작에 대해 논의합니다. 또한 요구 사항 모델을 아키텍처 모델과 별개로 유지해야 합니다.

• 일반적으로 기술 전문가가 아닌 관련자도 약간의 지침을 제공하면 큰 문제 없이 UML 다이어그램을 이해할 수 있습니다.

작업 항목에 모델 연결

요구 사항 워크숍 이후에 요구 사항 모델의 세부 정보를 상세히 기술하고 개발 작업에 모델을 연결합니다. Team Foundation의 작업 항목을 모델의 요소에 연결하여 이를 수행할 수 있습니다. 이 작업을 수행하는 방법을 보려면 방법: 모델 요소에서 작업 항목으로 연결을 참조하십시오.

어떤 요소라도 작업 항목에 연결할 수 있지만 가장 유용한 요소는 다음과 같습니다.

• 사용 사례. 사용 사례를 해당 사용 사례를 구현할 개발 작업에 연결할 수 있습니다.

• 사용 사례 확장. 반복에서 사용 사례의 요소 중 하나만 구현할 경우에는 하나 이상의 확장과 함께 사용 사례를 기본 사용 사례로 나눌 수 있습니다. 확장은 «extend» 관계를 사용하여 기본 사례에 연결된 사용 사례입니다. 사용 사례 확장에 대한 자세한 내용은 UML 사용 사례 다이어그램: 참조를 참조하십시오.

• 비즈니스 규칙 또는 서비스 품질 요구 사항을 기술하는 주석. 자세한 내용은 사용자 요구 사항 모델링을 참조하십시오.

테스트에 모델 연결

요구 사항 모델을 사용하면 승인 테스트의 디자인을 관리할 수 있습니다. 이러한 테스트는 개발 작업과 동시에 만들어야 합니다.

이 기법에 대한 자세한 내용은 모델에서 테스트 개발을 참조하십시오.

남은 작업 예상

요구 사항 모델을 사용하면 각 반복의 크기를 기준으로 프로젝트의 전체 크기를 예상할 수 있습니다. 또한 사용 사례와 클래스의 수 및 복잡성을 평가하면 필요한 개발 작업을 예상할 수 있습니다. 처음 몇 개의 반복을 완료한 경우 적용된 요구 사항과 적용할 요구 사항을 비교하면 남은 프로젝트의 비용과 범위를 대략적으로 계산할 수 있습니다.

각 반복이 거의 끝나는 시점에서 이후 반복에 대한 요구 사항 할당을 검토하십시오. 이렇게 하면 각 반복이 끝날 때 소프트웨어의 상태를 사용 사례 다이어그램의 하위 시스템으로 나타내는 데 유용합니다. 논의할 때 사용 사례 및 사용 사례 확장을 하나의 하위 시스템에서 다른 하위 시스템으로 이동할 수 있습니다.

추상화 수준

모델은 소프트웨어에 따라 추상화 범위를 가집니다. 가장 구체적인 모델은 프로그램 코드를 직접 나타내고, 가장 추상적인 모델은 코드에 나타내거나 나타내지 않는 비즈니스 개념을 나타냅니다.

모델은 여러 종류의 다이어그램을 통해 볼 수 있습니다. 모델 및 다이어그램에 대한 자세한 내용은 소프트웨어 디자인용 모델 개발을 참조하십시오.

다양한 종류의 다이어그램은 서로 다른 추상화 수준에서 디자인을 기술하는 데 도움이 됩니다. 대부분의 다이어그램 형식은 2 이상의 수준에서 유용합니다. 이 표에서는 각 다이어그램 형식이 사용되는 방식을 보여 줍니다.

외부 리소스

참고 항목

개념

소프트웨어 디자인용 모델 개발

사용자 요구 사항 모델링

소프트웨어 시스템의 아키텍처 모델링

모델에서 테스트 개발

기타 리소스

Visual Studio 2010 아키텍처 도구 사용 지침

Agile 개발에서 모델 사용

모델링 솔루션 구성