Microsoft Visual Studio Team System 2005 둘러보기

Microsoft Corporation

2005년 9월

적용 대상:
Microsoft Visual Studio Team System 2005

요약: 이 문서에서는 Microsoft Visual Studio Team System의 기능을 소개하고 이러한 기능이 소프트웨어 개발 프로세스를 지원하는 방법에 대해 설명합니다.

소개

고품질의 소프트웨어를 정해진 시간과 예산에 맞게 개발하는 것은 여전히 어려운 일입니다. 여기에는 여러 가지 이유가 있겠지만 우선적으로 소프트웨어 개발이 단순히 소프트웨어 개발자만의 책임이 아니라는 점을 들 수 있습니다. 실제로 소프트웨어 프로젝트에는 여러 다른 역할이 포함되어 있으며 이러한 역할이 서로 협력하는 방식에 따라 프로젝트의 성공이 좌우됩니다. 일반적으로 프로젝트 팀은 프로젝트 관리자, 비즈니스 분석가, 응용 프로그램 설계자, 개발자 및 테스터로 구성됩니다. 그러나 불행하게도 대부분의 경우에 공동 작업에 도움이 되는 도구가 없기 때문에 이러한 구성원이 서로의 노력을 조정하는데 어려움이 있습니다. 이러한 상황에서 팀 구성원의 작업 생산성, 정확성 및 예측 가능성을 향상시키는 동시에 소프트웨어 개발 수명 주기 동안 정보 공유와 공동 작업을 용이하게 하는 도구가 있다면 정말 유용하지 않겠습니까? 이러한 도구가 바로 여기에서 설명하고자 하는 Microsoft Visual Studio Team System입니다.

Visual Studio Team System은 Visual Studio 제품군에 추가된 Microsoft의 최신 제품입니다. Microsoft가 처음으로 전체 소프트웨어 개발 수명 주기에 초점을 맞추고 있다는 점에서 이 릴리스는 매우 중요합니다. Microsoft Visual Studio 2005 기능에 기반을 두는 Team System은 설계자, 개발자, 테스터 및 프로젝트 관리자를 지원하는 추가 기능을 제공합니다. 그림 1은 역할(소프트웨어 설계자, 소프트웨어 개발자, 소프트웨어 테스터 및 팀 기반)을 기준으로 하는 네 개의 Team System 버전을 보여 줍니다.

그림 1. Microsoft Visual Studio Team System

Team System은 소프트웨어 개발 프로세스의 더 광범위한 측면을 다루는 새로운 도구 집합을 제공합니다. 또한 Team System은 자신만의 고유한 프로세스에 맞게 이러한 프로세스를 사용자 지정하고 새 프로세스로 확장하며 기존 도구 및 프로세스와 통합할 수 있는 플랫폼을 제공합니다. 이 문서의 나머지 부분에서는 Team System의 기능과 이러한 기능이 팀과 프로세서에 어떤 도움을 줄 수 있는지 살펴보도록 하겠습니다.

소프트웨어 설계자용 Team System

Team Architect의 기능은 처음에 공개적인 베타 형태로 릴리스되었으며 원래는 "Whitehorse"라는 코드명을 갖고 있었습니다. 현재 Distributed System Designers이라고 부르는 이러한 기능으로 인해 모델링은 Visual Studio의 필수적인 새 기능이 되었습니다. 이러한 디자이너는 단순히 매력적인 다이어그램을 만들 뿐만 아니라 코드가 작성되기 전에 응용 프로그램 및 시스템 디자인이 배포에 적합한지 평가합니다. 예를 들어, 응용 프로그램 설계자는 배포에 맞게 서비스 지향 응용 프로그램 및 응용 프로그램 시스템을 디자인 및 평가할 수 있습니다. 인프라 설계자는 이러한 응용 프로그램이 배포되는 데이터 센터의 논리적 표현을 디자인할 수 있습니다. 그런 다음 응용 프로그램 설계자와 인프라 설계자는 서로 협력하여 응용 프로그램 디자인과 데이터 센터 디자인이 호환되도록 할 수 있습니다. 응용 프로그램을 구현하기 위해 작성된 코드는 응용 프로그램 디자인과 동기화 상태를 유지합니다. Team Architect에서 모델링할 수 있는 일부 항목은 Microsoft가 제공하는 DSI(Dynamic Systems Initiative)의 초기 작업을 나타냅니다. DSI에 대한 자세한 내용은 "Dynamic Systems Initiative"를 참조하십시오.

Team Architect의 모든 Distributed System Designer는 모델 정의를 저장하는 XML 기반 형식인 SDM(System Definition Model)을 활용합니다. SDM은 응용 프로그램 시스템과 데이터 센터 인프라를 설명할 수 있는 공통 언어를 제공합니다. 이 공통 언어를 사용하면 각 분야의 전문가 사이에 의견을 더 효율적으로 교환할 수 있으며 응용 프로그램을 대상 데이터 센터 환경에 성공적으로 배포하여 실행할 수 있는지 확인하기 위해 응용 프로그램의 유효성을 검사할 수 있습니다. 다음 절에서는 Team Architect에서 사용할 수 있는 네 가지 Distributed System Designer에 대해 설명합니다.

Logical Datacenter Designer

현재 존재하는 응용 프로그램 호스팅 환경과 이러한 환경의 구성, 제약 및 연결 방법을 이해해야 하는 개발자에게 있어 데이터 센터의 물리적 인프라는 일반적으로 중요하지 않습니다. Logical Datacenter Designer는 데이터 센터에 있는 물리적 시스템이나 시스템 유형을 나타내지 않는 논리 데이터 센터 다이어그램을 만드는 데 사용됩니다. Microsoft Internet Information Server, Microsoft SQL Server, Microsoft BizTalk Server 등과 같은 응용 프로그램 서버 소프트웨어의 특정 구성을 정의하거나 문서화하고 (응용 프로그램) 서버의 구성된 논리적 표현이 어떤 방식으로 상관되는지 나타내기 위해 논리 데이터 센터 다이어그램이 사용됩니다. 논리 서버는 논리 통신 경계를 정의하는 영역 내에서 그룹화될 수 있습니다. 영역에 포함될 수 있는 논리 서버의 종류와 데이터 센터 안과 밖으로 보내지는 통신의 방향과 종류를 제한하기 위해 영역을 구성할 수 있습니다. 표 1에는 이 디자이너에 의해 모델링될 수 있는 요소가 나열되어 있으며 그림 2는 논리 데이터 센터 다이어그램의 간단한 예제를 보여 줍니다.

표 1. Logical Datacenter Designer 요소

논리 서버	설명
WindowsClient	Windows 운영 체제에서 제공되는 Windows 응용 프로그램 호스팅 환경입니다. WindowsApplications, GenericApplications 및 OfficeApplications를 호스팅하도록 Windows 클라이언트를 구성할 수 있습니다.
IISWebServer	Internet Information Server의 구성을 나타냅니다. IIS를 지정하여 Microsoft ASP.NET 웹 응용 프로그램, 웹 서비스 또는 다른 일반 응용 프로그램을 호스팅할 수 있습니다.
DatabaseServer	데이터베이스를 호스팅할 수 있는 일반 데이터베이스 서버를 나타냅니다.
GenericServer	GenericServer는 대개 일반 응용 프로그램의 호스팅을 지원하기 위해 사용되는 미리 정의된 논리 서버의 하나에 의해 적절하게 설명되지 않는 응용 프로그램 호스팅 환경을 나타냅니다.
영역	논리 서버의 그룹입니다.
종점	종점은 논리 서버 또는 영역의 통신 지점을 나타냅니다. 논리 서버는 서버로부터의 통신을 허용하는 클라이언트 종점과 서버로의 통신을 허용하는 서버 종점을 지원할 수 있습니다. 영역 종점은 영역 내의 서버나 영역과 주고 받은 통신이 통과하는 “관문”으로 생각할 수 있습니다. 영역 종점을 정의하여 인바운드, 아웃바운드 또는 양방향 통신을 허용하거나 허용되는 통신의 종류를 제한할 수 있습니다. 영역 종점 외에도 클라이언트 및 서버 형태의 종점, 즉 데이터베이스 종점, HTTP 종점, 웹 사이트 종점 및 일반 종점이 허용됩니다.
설명	디자인 요소에 대한 설명을 모델 표면에 추가할 수 있게 합니다.

그림 2. 논리 데이터 센터 다이어그램(큰 그림으로 보려면 이미지를 클릭)

속성을 사용자 지정하여 다이어그램의 논리 서버와 영역에 추가한 후에는 나중에 사용하기 위해 이러한 도형을 도구 상자에 추가할 수 있습니다. 이렇게 하려면 하나 또는 여러 개의 영역이나 서버를 선택하고 마우스 오른쪽 단추를 클릭한 다음 도구 상자에 추가(Add to Toolbox)를 클릭합니다.

다이어그램에 배치하는 각 논리 서버나 영역에 대해 일련의 제약 조건 및 설정을 지정할 수 있습니다. 이렇게 하려면 보기(View) 메뉴에서 다른 창(Other Windows)을 클릭한 다음 설정 및 제약 조건(Settings and Constraints)을 클릭합니다. 여기에서는 서버에 배포할 응용 프로그램이 따라야 하는 각 서버의 운영 특징에 대한 정책을 지정할 수 있습니다. 예를 들어, 그림 3에서 설정 및 제약 조건 편집기(Settings and Constraints Editor)에는 유효한 인증 메커니즘으로 폼 및 Windows 인증만 허용되는 서버가 나와 있습니다. 제약 조건 머리글 아래의 선택된 항목 목록을 보면 ASP.NET 웹 응용 프로그램에서 BizTalk 웹 서비스 및 일반 응용 프로그램에 이르기까지 거의 모든 유형의 서비스를 이 서버에서 실행할 수 있음을 알 수 있습니다. 이러한 사실은 이 문서의 뒤에서 Deployment Designer를 설명할 때 중요합니다. 또한 이 도구에서는 웹 사이트 종점을 비롯한 IIS의 전체 구성을 기존 서버에서 가져올 수 있습니다. 이렇게 하려면 논리 서버를 마우스 오른쪽 단추로 클릭한 다음 설정 가져오기(Import Settings)를 클릭합니다.

그림 3. 설정 및 제약 조건 편집기(큰 그림으로 보려면 이미지를 클릭)

Application Designer

저 같은 경우에는 새 솔루션을 설계할 때 칠판에 솔루션을 그리는 일을 가장 먼저 하게 됩니다. 그런 다음 모델을 지속적으로 구체화하면서 더 심층적인 디자인과 기능적 분해를 거쳐 최종적으로 모델을 작성합니다. Application Designer는 이전에 칠판에 그릴 때는 알지 못했던 것들을 파악하면서 응용 프로그램을 디자인 및 구성할 수 있는 도구를 제공한다는 점에서 이러한 프로세스에서 매우 중요한 역할을 수행합니다. 이제 응용 프로그램 다이어그램을 사용하여 솔루션을 응용 프로그램(웹 서비스, 스마트 클라이언트, 웹 사이트 등과 같이 별도로 배포할 수 있는 코드 단위)으로 분해할 수 있습니다. 표 2에는 응용 프로그램 다이어그램에서 응용 프로그램을 디자인하는 데 사용할 수 있는 일부 요소가 나와 있으며 그림 4는 샘플 응용 프로그램 다이어그램을 보여 줍니다.

표 2. Application Designer 요소

디자인 요소	설명
Windows 응용 프로그램	Microsoft Windows Forms 또는 콘솔 스타일 응용 프로그램입니다.
ASP.NET 웹 응용 프로그램	웹 서비스 종점 및/또는 웹 콘텐츠 종점을 가질 수 있는 ASP.NET 웹 응용 프로그램입니다. 기본 웹 콘텐츠 종점을 가진 ASP.NET 응용 프로그램을 작성하는 두 개의 도구 상자가 제공됩니다.
Office 응용 프로그램	Microsoft Word 또는 Microsoft Excel과 같은 Microsoft Office 응용 프로그램과 통합되는 응용 프로그램입니다.
외부 웹 서비스	응용 프로그램에 사용되며 솔루션 외부에 위치하는 웹 서비스입니다. 나타내려는 웹 서비스의 URL을 지정해야 합니다.
외부 데이터베이스	솔루션의 응용 프로그램에 사용되는 데이터베이스입니다. 나타내려는 데이터베이스에 대한 연결 문자열을 제공할 수 있습니다.
BizTalk 웹 서비스	BizTalk 웹 서비스에 알려지는 웹 서비스입니다. 나타내려는 웹 서비스의 URL을 지정해야 합니다.
일반 응용 프로그램	솔루션과 상호 작용하지만 연관된 디자인 요소가 없는 다른 유형의 응용 프로그램입니다. 예를 들어, 일반 응용 프로그램 디자인 요소를 사용하여 레거시 응용 프로그램을 모델링할 수 있습니다.
웹 서비스 종점	응용 프로그램의 웹 서비스 진입점입니다.
웹 콘텐츠 종점	ASP.NET 웹 응용 프로그램 디자인 요소의 웹 콘텐츠 진입점입니다.
일반 종점	특수하게 모델링되지 않은 종류의 응용 프로그램에 있는 연결 지점을 나타내는 데 사용되는 일반 종점입니다. 모든 종류의 응용 프로그램에 일반 종점을 추가할 수 있습니다.
설명	디자인 요소에 대한 설명을 다이어그램 표면에 추가할 수 있게 하는 표식입니다.

그림 4. 응용 프로그램 다이어그램(큰 그림으로 보려면 이미지를 클릭)

Logical Datacenter Designer와 비슷하게 설정 및 제약 조건 편집기를 사용하여 추가 제약 조건 및 속성을 응용 프로그램 정의와 종점에 추가할 수 있습니다. 이러한 제약 조건은 응용 프로그램의 배포 요구 사항을 지정하며 응용 프로그램을 배포할 수 있는 논리 서버 유형을 제한합니다. 또한 Application Designer를 사용하면 웹 서비스에 대한 작업을 정의할 수 있습니다. 예를 들어, ASP.NET 웹 응용 프로그램에서 웹 서비스 공급자 종점을 선택하고 웹 서비스 정보(Web Service Details) 창을 사용하여 웹 서비스 인터페이스를 정의하는 메서드와 매개 변수를 정의할 수 있습니다.

제공된 대부분의 응용 프로그램 유형은 구현 및 코드와의 동기화를 지원합니다. Windows 응용 프로그램 또는 ASP.NET 웹 응용 프로그램과 같은 응용 프로그램을 마우스 오른쪽 단추로 클릭하거나 응용 프로그램 다이어그램을 마우스 오른쪽 단추로 클릭하고 응용 프로그램 구현(Implement Application) 또는 모든 응용 프로그램 구현(Implement All Applications)을 클릭할 경우 Visual Studio는 해당 유형 또는 지정된 언어(Microsoft Visual Basic, Microsoft Visual C# 또는 Microsoft Visual J#)에 따라 선택한 응용 프로그램에 대한 프로젝트를 만듭니다. 다이어그램에서 응용 프로그램이 연결되어 있는 경우 Visual Studio는 응용 프로그램을 연결하여 웹 참조를 작성하고 필수 구성 항목을 채웁니다. 솔루션이 이미 존재하거나 응용 프로그램을 코드에서 직접 정의하는 것을 더 선호할 경우에는 응용 프로그램 다이어그램을 솔루션에 추가하기만 하면 프로젝트, 코드 및 구성 파일에서 다이어그램이 리버스 엔지니어링됩니다. 프로젝트 및 코드와 함께 솔루션에 응용 프로그램 다이어그램이 존재하면 나중에 다이어그램이나 코드가 변경될 경우 Visual Studio는 다이어그램과 SDM 모델을 프로젝트, 코드 및 구성 파일과 백그라운드에서 자동으로 동기화합니다.

System Designer

System Designer를 사용하면 그림 5에 나온 것처럼 응용 프로그램 다이어그램에 정의된 응용 프로그램이나 다른 시스템 다이어그램에 정의된 시스템으로 구성되는 “배포 단위”인 응용 프로그램 시스템을 디자인할 수 있습니다. 시스템이 응용 프로그램의 사용자 지정 구성이기 때문에 이전에 제공했던 기본값에서 개별 응용 프로그램을 재정의하거나 하나 또는 여러 개의 동일한 응용 프로그램 정의 또는 시스템 정의를 시스템에 포함할 수 있습니다. 그림 5에 나온 것처럼 각 응용 프로그램은 각각의 정의나 배포 방법에 따라 서로 다르게 연결 및 구성할 수 있습니다. 예를 들어 해당 정의에서 재정의 가능한 것으로 지정되어 있는 응용 프로그램의 설정을 재정의할 수 있습니다. 실제로 각각 개별 배포 구성이나 데이터 센터 구성을 나타내는 여러 시스템에 대한 정의를 동일한 솔루션에서 만들 수 있습니다. 이렇게 하면 동일한 솔루션을 실행하는 서로 다른 데이터 센터를 가진 여러 고객을 지원하는 데 도움이 됩니다. 시스템을 만들려면 응용 프로그램 다이어그램에서 원하는 응용 프로그램을 선택한 다음 응용 프로그램 다이어그램을 마우스 오른쪽 단추로 클릭하고 응용 프로그램 시스템 디자인(Design Application System)을 클릭합니다.

그림 5. 시스템 다이어그램(큰 그림으로 보려면 이미지를 클릭)

Deployment Designer

Deployment Designer를 사용하면 Logical Datacenter Designer로 만든 논리 데이터 센터 다이어그램에 시스템 디자인을 매핑하여 시스템에 대한 논리 배포를 설명할 수 있습니다. Deployment Designer는 올바른 유형의 응용 프로그램을 올바른 유형의 논리 서버에 매핑함으로써 논리 데이터 센터 다이어그램에서 논리 서버에 설정되었을 수 있는 모든 응용 프로그램 호스팅 제약 조건이 제대로 적용되도록 합니다. 시스템의 모든 응용 프로그램이 매핑된 후에는 추가 다이어그램 유효성 검사를 수행하여 Application Designer 또는 System Designer에 구성된 모든 제약 조건과 설정을 논리 데이터 센터 디자인에 대해 검사할 수 있습니다. 이렇게 하면 코드를 작성하기 전에 구성에 문제가 없는지 파악하는 데 도움이 됩니다. 컴파일러 오류 및 경고와 비슷하게 유효성 검사 오류가 Visual Studio에서 표시됩니다. 이러한 오류를 두 번 클릭하면 응용 프로그램 다이어그램 또는 논리 데이터센터 다이어그램으로 이동하고 문제가 있는 응용 프로그램 또는 논리 서버가 선택되며 문제를 야기한 구성 설정이 열립니다. 응용 프로그램을 구현하고 설정을 변경한 후에는 변경 사항이 구성 파일에 즉시 반영되므로 유효성 검사에 의한 정보가 개발 프로세스에 직접 제공됩니다.

자동차를 만들기 전에 실시하는 충돌 테스트와 같은 이 모델 유효성 검사를 사용하면 데이터 센터의 정책을 응용 프로그램에서 항상 준수하도록 할 수 있으며 솔루션 수명 주기 동안에 변경 사항이 끼치는 영향을 응용 프로그램 아키텍처 또는 데이터 센터 관점에서 파악할 수 있습니다.

소프트웨어 개발자용 Team System

Visual Studio는 이미 코드 작성을 위한 뛰어난 도구로 널리 알려져 있습니다. Team Developer는 코드 기반을 대상으로 한 코드 분석 및 실행 중인 파일에 대한 동적 분석(성능 프로파일링 및 코드 적용 범위 정보를 수집하기 위한)을 수행하기 위한 도구와 완전하게 통합된 단위 테스트 프레임워크를 개발자에게 제공하여 고품질 코드를 작성할 수 있게 함으로써 Visual Studio를 향상시킵니다.

코드 분석

FxCop 및 PreFast와 같은 시간 기반 도구에 기초하는 Visual Studio Team System에서 제공되는 코드 분석 도구는 코드가 작성되는 동안에 코드를 분석합니다. 이러한 도구는 사용자가 지정한 규칙과 일치하는 특정 결함 패턴을 코드에서 분석할 수 있는 기능을 제공합니다. .NET 언어로 작성된 관리 코드를 분석할 수 있게 하려면 그림 6에 나온 것처럼 관리 코드 프로젝트의 속성(Properties) 대화 상자로 이동하여 코드 분석(Code Analysis) 탭을 클릭하고 코드 분석 사용(Enable Code Analysis)을 선택합니다.

그림 6. 코드 분석 사용

위 그림에 나온 것처럼 코딩 및 디자인 지침을 검사하는 규칙에서 보안 문제를 검사하는 규칙에 이르기까지 수십 개의 규칙이 이미 정의 및 활성화되어 있습니다. 프로젝트에 적용되지 않는 규칙을 비활성화할 수 있을 뿐만 아니라 특정 코드 패턴을 찾는 고유한 규칙을 만들 수 있습니다. Visual Studio는 코드의 문제가 규칙에서 탐지될 경우 해당 규칙을 구성한 방법에 따라 경고나 오류가 발생합니다.

또한 코드 분석 도구를 사용하여 네이티브 Microsoft C++ 코드의 품질을 향상시킬 수 있습니다. 얘를 들어, 이러한 도구를 사용하여 버퍼 오버런, 초기화되지 않은 메모리 및 널 포인터 참조 해제를 식별할 수 있습니다. 이러한 문제는 컴파일러 경고와 같은 방식으로 보고되며 #pragma 컴파일러 지시문을 사용하여 경고 표시를 해제할 수 있습니다.

동적 분석

동적 코드 분석 도구 집합에는 런타임에 응용 프로그램의 성능을 측정하기 위한 코드 프로파일러가 포함되어 있습니다. 프로파일링 모드에는 샘플링과 계측(instrumentation)의 두 가지 모드가 있습니다.

샘플링은 가끔씩 응용 프로그램 성능 샘플을 가져와 진행 중인 상황을 확인합니다. 이러한 형태로 분석을 수행하면 프로파일링 작업의 실행 시간이 매우 짧기 때문에 응용 프로그램의 성능에 영향을 줄 가능성이 줄어듭니다. 그러나 이 방법은 통계적 특성으로 인해서 응용 프로그램 타이밍을 정확하게 나타내지 않습니다.

반면에 계측은 응용 프로그램이 수행하는 작업에 대한 완전한 설명을 제공합니다. 이는 코드의 모든 프로시저와 메서드 호출을 빠짐없이 계측하는 작업을 응용 프로그램이 실행되기 전에 프로파일러에서 수행하기 때문입니다. 따라서 프로파일러는 호출된 메서드와 메서드를 실행하는 데 걸린 시간을 정확하게 추적할 수 있습니다. 그림 7에 나온 것처럼 더 많은 코드가 실행되고 더 많은 데이터가 수집되기 때문에 계측 기반 프로파일링을 사용하면 응용 프로그램의 성능이 저하됩니다.

그림 7. 계측 프로파일링의 결과(큰 그림으로 보려면 이미지를 클릭)

단위 테스트

단위 테스트는 항상 소프트웨어 개발 프로세스의 중요한 부분이었습니다. 단위 테스트는 시스템의 한 측면(특정 함수 또는 프로시저, 구성 요소 또는 사용 시나리오)에 대한 유효성 검사를 수행하는 특정 유형의 테스트를 말합니다. Team System은 Team Developer 및 Team Test에서 단위 테스트를 작성 및 실행하기 위한 프레임워크를 제공하며 개발 IDE와의 긴밀한 통합을 제공합니다. 코드 샘플 1에 나온 것처럼 단위 테스트는 테스트를 받는 제품의 해당 함수 또는 프로시저의 동작(behavior)을 확인하는 특성 사용 테스트 함수입니다. 그림 8에 나온 것처럼 [TestMethod] 특성이 테스트 코드에 추가되고 나면 Visual Studio는 이를 단위 테스트로 인식하고 테스트 관리자(Test Manager) 창에 함수를 표시합니다.

[TestMethod()]
public void AdditionTest()
{
Math target = new Math();

int x = 5; 

int y = 5; 

int expected = 10;
int actual;

actual = target.Addition(x, y);
Assert.AreEqual(expected, actual, 
  "Math.Addition did not return the expected value.");

}

코드 샘플 1. 간단한 단위 테스트

그림 8. Visual Studio에서 테스트 관리(큰 그림으로 보려면 이미지를 클릭)

테스트 관리자(Test Manager)를 사용하면 단위 테스트를 선택 및 실행할 수 있을 뿐만 아니라 테스트 목록으로 그룹화, 필터링 및 구성할 수 있습니다. 테스트 관리자(Test Manager)를 통해 관리되는 각 테스트는 연관된 작업 항목 목록뿐만 아니라 우선 순위, 소유자 및 클래스 이름을 비롯한 다른 메타데이터를 가질 수 있습니다.

코드 적용 범위

단위 테스트 실행 도중에 실제로 수행된 코드 양을 알 수 있다면 정말 유용하지 않겠습니까? 이러한 유형의 분석을 코드 적용 범위라고 합니다. Team Developer 및 Team Test는 둘 다 단위 테스트를 실행하고 이러한 테스트 도중에 실행되는 코드 줄을 추적할 수 있는 기능을 제공합니다. 이 기능을 통해 확인된 결과는 모든 코드 줄을 테스트하거나 테스트 방법이 어느 정도나 완벽한지 파악하는 데 필요한 다른 단위 테스트가 무엇인지 알려줍니다. 그림 9 및 그림 10은 코드 적용 범위 분석의 결과를 보여 줍니다. 그림 9에서 녹색으로 표시된 코드 줄은 단위 테스트 실행 도중에 실행된 줄을 나타내고 빨간색으로 표시된 코드 줄은 전혀 실행되지 않은 코드를 나타냅니다.

그림 9. 코드 창에 있는 코드 적용 범위 결과

그림 10. 코드 적용 범위 통계(큰 그림으로 보려면 이미지를 클릭)

소프트웨어 테스터용 Team System

제가 대학에 다닐 때 교수님 중에서 한 분은 정말 열심히 공부해야만 소프트웨어 테스터가 될 수 있을 것이라고 말한 적이 있었습니다. 그만큼 소프트웨어 테스터가 어려운 작업이기 때문에 오늘날과 같이 신속하게 비즈니스 솔루션을 작성해야 하는 상황 속에서는 흔히 소프트웨어 품질을 보증하기 위한 노력을 건너뛰려는 유혹을 받게 됩니다. 또한 소프트웨어 개발 프로젝트에 테스트가 포함되어 있는 조직에서 테스트 요구를 충족하는 통합 도구를 제대로 선택하지 못하고 제대로 통합되지 않은 고가의 소프트웨어 테스트 솔루션을 구입하는 경우가 많습니다. Microsoft는 개발자와 테스터를 위한 일련의 통합 테스트 도구를 제공함으로써 이러한 문제를 해결했습니다.

표 3. Team System 테스트 유형

테스트 유형	설명
단위 테스트	단위 테스트는 응용 프로그램 함수와 메서드를 테스트하는 코드 비트입니다. 단위 테스트는 기존 소스 코드를 테스트하는 데 사용되며 테스트 기반 개발의 핵심입니다.
웹 테스트	웹 테스트를 사용하면 모든 웹 페이지에 대한 작업을 기록할 수 있습니다. 작업을 기록한 후에는 웹 테스트를 수정하고 코드로 변환하고 각 요청의 반환 결과에서 유효성 검사 및 추출 규칙을 추가할 수 있습니다.
정렬된 테스트	정렬된 테스트를 사용하면 개수와 상관 없이 다른 단위 테스트 또는 웹 테스트를 그룹화하고 순서대로 나열할 수 있습니다.
로드 테스트	로드 테스트를 사용하면 정의된 로드 패턴에 따라서 웹 테스트 및 단위 테스트의 임의 조합을 반복해서 재생할 수 있습니다. 또한 동시 사용자 수, 브라우저 유형, 통신 회선 특징 등과 같은 로드 특성을 지정할 수 있습니다.
수동 테스트	수동 테스트는 응용 프로그램에 있는 일부 기능의 유효성을 검사하기 위해 테스터가 실행해야 하는 일련의 수동 단계를 정의합니다. Team System은 수동 테스트(Word 또는 텍스트 형식)를 정의하기 위한 메커니즘을 제공합니다. 또한 이러한 테스트는 다른 테스트 유형과 함께 관리 및 실행될 수 있습니다.
일반 테스트	일반 테스트는 Visual Studio에서 테스트로 작동하도록 래핑되는 기존 프로그램입니다.

Team Foundation Server

Team Foundation Server가 제공하는 기능은 Team System에 포함된 기능 중에서 가장 중요할 것입니다. Team Foundation에서 제공되는 새 소스 제어 관리 시스템, 작업 항목 추적 기능, 빌드 자동화, 통합 분석 및 보고, 통합 공동 작업 프로젝트 사이트 등으로 인해 전체 팀을 순조롭게 진행할 수 있습니다. 또한 Team Foundation은 Microsoft Project 및 Microsoft Excel 2003의 통합을 통해 프로젝트 관리 기능을 제공합니다.

소스 제어 관리

Microsoft VSS(Visual SourceSafe)는 Microsoft 개발자를 위한 가장 일반적인 소스 코드 제어 시스템 중 하나이며 수 년 동안 소프트웨어 개발자를 위해 중요한 역할을 수행해 왔습니다. 그러나 VSS는 확장성, 안정성 및 견고성이 부족하며 여러 표준 시간대와 인터넷 상에서 사용될 수 없습니다. Visual Studio Team Foundation에는 이러한 문제를 모두 해결하는 새로운 소스 제어 엔진이 함께 제공됩니다. Team Foundation의 소스 제어 서버 구성 요소는 Microsoft SQL Server 2005를 활용하며 HTTP 및 HTTPS 상에서도 문제 없이 작동하는 적절한 아키텍처와 확장성을 가진 소스 제어 솔루션입니다. 또한 이러한 구성 요소는 해외 개발 팀에 요구되는 것처럼 여러 지역에 걸친 다양한 개발을 수월하게 만드는 기능(예: 표준 시간대 인식)을 지원합니다. 이외에도 Team Foundation의 소스 제어 솔루션은 체크 인 정책(체크 인 프로세스를 제어하는 규칙)을 지원하여 소프트웨어 개발 프로세스에서 중요한 역할을 수행합니다. 예를 들어, 작업 항목과 완료된 실제 개발 작업 사이에 추적이 가능할 수 있도록 체크 인 프로세스 이전에 적어도 하나 이상의 작업 항목과 체크 인을 연관시키는 것을 개발자에게 요구할 수 있습니다. 또한 코드 분석의 실행을 요구하거나 체크 인 작업 전에 모든 단위 테스트를 실행할 것을 요구하는 체크 인 정책을 만들 수 있습니다. 개발자가 이러한 정책을 무시해야 하는 경우 예외를 설명하는 알림 전자 메일 메시지를 관련 팀 구성원에게 자동으로 보낼 수 있습니다. 그림 11 및 그림 12는 프로젝트 관리자가 체크 인 정책과 체크 인 메모를 제어할 수 있는 방법을 보여 줍니다.

그림 11. 체크 인 정책 추가

그림 12. 체크 인 메모 추가

Team Foundation의 소스 제어가 제공하는 또 다른 주요 기능은 셸빙(shelving)입니다. 셸빙을 사용하면 서버에 있는 “셀프(shelf) 집합”에 체크 아웃된 코드를 둘 수 있으며 셀프에서 꺼낼 때까지 체크 아웃된 코드는 이곳에서 유지됩니다. 따라서 기본적으로 라이브 트리의 기존 코드를 덮어쓰거나 손상시키지 않고 서버의 셀프에 작업 중인 코드를 저장할 수 있습니다. 여러 컴퓨터를 사용하거나 부분적으로 완료된 작업을 다른 개발자에게 전송하거나 현재의 변경 사항을 잠시 제쳐두고 우선 순위가 높은 문제로 신속하게 전환하려는 경우에 이 방법이 유용합니다.

작업 항목 추적

앞에서 언급한 것처럼 작업 항목은 팀의 누군가에 의해 할당 및 완료될 수 있는 “항목”입니다. 가장 단순한 수준에서 보면 작업 항목은 간단한 상태 전환(예: “열림” 및 “닫힘”)을 가지는 간단한 작업이 될 수 있습니다. 그러나 대부분의 프로젝트는 각각 고유한 특성과 워크플로 상태 및 전환을 가지는 여러 다른 유형의 작업 항목을 포함합니다. 작업 항목의 또 다른 예로는 버그, 문제, 위험 또는 기능이 있습니다. 모든 작업 항목은 유형에 상관 없이 Team System에 저장됩니다. 새 프로젝트를 만들 경우 또한 프로젝트의 정의에 따라 만들 수 있는 작업 항목의 수와 유형이 결정됩니다. 각 작업 항목 유형은 고유한 상태와 전환을 가질 수 있으며 일반적으로 말해서 각 작업 항목을 누군가에게 할당하여 대상 반복 또는 릴리스, 우선 순위 등과 같은 정보를 제공할 수 있습니다. 또한 작업 항목을 다른 작업 항목, 소스 제어의 파일, 소스 제어의 변경 집합 등에 연결할 수 있습니다. 작업 항목을 서로 연결하거나 파일 및 소스 코드와 같은 다른 항목 사이에 연결할 수 있을 경우 거의 모든 소프트웨어 개발 프로젝트에서 필요한 추적 기능이 제공됩니다. 이 모델은 매우 광범위한 모델이므로 특정 프로젝트 요구를 지원하도록 필요에 따라 변경할 수 있습니다.

그림 13. 추적 기능을 위한 작업 항목 사용 예제

그림 14 및 그림 15에 나온 것처럼 Team System은 작업 항목 모음을 제공하며 Microsoft Project, Microsoft Excel 및 Visual Studio에서 Team Explorer에 이르기까지 다양한 도구를 사용하여 이러한 작업 항목과 상호 작용할 수 있습니다.

그림 14. Visual Studio에서의 작업 항목 정의(큰 그림으로 보려면 이미지를 클릭)

그림 15. Excel에서의 작업 항목(큰 그림으로 보려면 이미지를 클릭)

빌드 자동화

빌드 자동화는 소프트웨어 개발 팀에게 매우 중요한 최상의 실행 방법입니다. Team System에서 Team Foundation Build와 함께 제공되는 빌드 자동화는 MSBuild를 활용하여 연관된 단위 테스트 및 코드 분석을 실행할 수 있으며 파일 서버에 빌드를 릴리스하고 나머지 팀 구성원에게 빌드 보고서를 게시할 수 있습니다. Team Foundation Build 결과 및 로그는 보고 및 분석을 위해 Team System 데이터 웨어하우스에 전파할 수 있습니다. 또한 Team Foundation Build는 소스 제어 및 작업 항목 추적과 같은 다른 Team System 도구와 완전하게 통합됩니다.

Team System에서는 고유한 요구에 맞게 정의 및 사용자 지정할 수 있는 여러 다른 빌드 유형을 가질 수 있습니다. 실제로 Team System은 그림 16과 같이 바로 작업을 시작할 수 있는 마법사를 제공합니다.

그림 16. 새 빌드 유형 정의

모든 빌드 결과는 유지 관리되며 Visual Studio 또는 빌드 보고서를 통해 볼 수 있습니다. 실제로 빌드 프로세스를 수행하는 다수의 빌드 시스템을 설정할 수 있으며 GUI 또는 명령줄을 통해 빌드 프로세스를 시작할 수 있다는 점에 주의합니다. 또한 그림 17에 나온 것처럼 빌드 결과를 전자 메일로 알리도록 Team System을 구성할 수 있습니다.

그림 17. 빌드 이벤트에 대한 경고 구성

보고

실제 작업에 기초하여 매주마다 팀의 작업 진척도가 어떻게 진행되고 있는지 볼 수 있는 보고서를 자동으로 생성할 수 있다면 정말 도움이 되지 않겠습니까? Team Foundation의 보고 기능을 사용하면 이러한 보고서를 생성할 수 있습니다. Team Foundation은 SQL Server 2005에 기반을 두고 작성되었으며 작업 항목, 품질 특성, 테스트 및 테스트 결과, 빌드 결과 등에 대한 모든 것을 저장합니다. 이러한 모든 정보는 SQL Server Analysis Services와 함께 집계되며 Team System의 보고 기능에 연결됩니다. 실제로 Team System이 제공하는 보고서는 SQL 2005 Reporting Services를 사용하여 작성됩니다. 이는 기존 보고서를 수정할 수 있으며 고유한 요구에 맞는 자신만의 보고서를 작성할 수 있음을 의미합니다.

수십 개의 보고서가 Team System에서 제공되는데(그림 18에는 샘플 보고서가 나와 있음) 이는 이러한 보고서가 새 Team System 프로젝트를 작성하는 도중에 사용되는 Team System 프로젝트 템플릿의 일부이기 때문입니다. Team System 프로젝트 템플릿을 사용자 지정하여 고유한 작업 항목 유형을 만들거나 기존 작업 항목 정의를 수정할 때 기본 보고서를 사용자 지정하고 싶을 것입니다.

그림 18. 샘플 보고서(큰 그림으로 보려면 이미지를 클릭)

프로젝트 사이트

새 Team System 프로젝트를 작성할 경우 프로젝트의 공동 작업을 향상시키기 위해 새 Microsoft Windows Sharepoint 사이트를 만들 것인지 묻는 메시지가 나타납니다. Microsoft Windows Sharepoint Services는 팀에서 작성한 프로젝트의 설명서를 위한 문서 관리 및 저장 기능을 제공합니다. 또한 Team System 프로젝트 템플릿 정의에 따라 Sharepoint 사이트의 구조와 내용이 정의되며 결과적으로 문서 라이브러리 구조 및 문서 템플릿이 정의됩니다. 실제로 프로젝트의 일부로 채워져야 하는 모든 항목이 포함된 프로젝트 포털 사이트를 만들도록 Team System을 구성하여 올바른 항목이 제때에 전달되도록 할 수 있습니다.

또한 Windows Sharepoint 사이트에는 사이트의 보고서를 직접 볼 수 있는 웹 파트가 포함되어 있습니다. Visual Studio가 없이 개발자가 아닌 프로젝트 관계자가 하나의 장소로 이동하여 프로젝트의 상태와 세부 사항을 자신의 브라우저에서 직접 볼 수 있다는 점에서 이것은 매우 중요한 기능입니다.

그림 19. 프로젝트 사이트(큰 그림으로 보려면 이미지를 클릭)

프로젝트 관리

프로젝트 관리자는 일반적으로 Microsoft Project 또는 Microsoft Excel을 사용하여 수행해야 할 작업을 관리합니다. Team System의 경우에는 팀 전체에서 다양한 유형의 작업 항목을 관리할 수 있어야 합니다. Visual Studio Team System에는 프로젝트 관리자가 작업 항목과 상호 작용할 수 있는 기본 제공 인터페이스가 포함되어 있습니다. 그러나 대개는 프로젝트 관리자가 가장 일반적으로 업무에 사용하던 도구를 계속 사용하도록 하는 것이 훨씬 더 자연스럽습니다. 따라서 Team System에서는 작업 항목을 Microsoft Excel 및 Microsoft Project와 동기화할 수 있습니다. 이러한 도구에서 프로젝트 관리자는 자연스럽고 편리한 방식으로 모든 작업 항목을 유형에 상관 없이 자유롭게 할당 및 추적할 수 있습니다.

또한 프로젝트 관리자에게 보고서는 매우 중요합니다. Team System에서 프로젝트 관리자는 제품과 함께 제공되는 수십 개의 기본 제공 보고서를 사용할 수 있을 뿐만 아니라 Microsoft Excel과 같은 분석 도구를 사용하여 Team System 데이터 웨어하우스에 연결함으로써 프로젝트 데이터를 분석할 수 있습니다. 또한 프로젝트 관리자는 각 Team System 프로젝트에 대해 작성된 Windows Sharepoint 사이트의 기능을 사용하여 통신을 용이하게 하고 모든 프로젝트 문서와 항목을 관리할 수 있습니다.

Team System 확장성 및 사용자 지정

앞에서 언급한 것처럼 Team System은 단순히 도구 집합이 아니라 플랫폼입니다. Team System의 확장성에 대해 논의할 때는 Team System을 확장할 수 있는 영역이 무엇인지 다루어야 할 것입니다. 다음 표에는 이러한 영역의 개요가 나와 있습니다.

표 4. Team System 확장성 요약

사용자 지정 영역	설명
프로젝트 템플릿	Team System 프로젝트 템플릿은 새 Team System 프로젝트를 작성하는 동안 사용되며 보고서, 작업 항목 정의, 소스 제어 정책, Windows Sharepoint Services 구조 및 내용, 프로세스 지침, 사용 권한 등을 비롯한 프로젝트의 모든 측면을 정의합니다. 조직 및 프로젝트 요구에 맞게 고유한 프로젝트 템플릿을 정의할 수 있습니다. 이러한 템플릿을 사용자 지정하기 위한 도구가 Team System에서 제공되지 않으므로 선호하는 XML 편집기를 사용하여 수정해야 합니다.
작업 항목	마찬가지로 선호하는 XML 편집기를 사용하여 고유한 작업 항목을 정의하거나 기존 작업 항목을 사용자 지정할 수 있습니다.
소스 제어	각 Team System 프로젝트에 대해 소스 제어 정책 및 체크 인 메모 필드를 정의할 수 있습니다.
빌드 유형	Visual Studio Team System 내에서 고유한 빌드 유형을 정의할 수 있습니다.
Windows Sharepoint Services 사이트	Windows Sharepoint 사이트 내에 포함된 문서를 수정할 수 있을 뿐만 아니라 Windows Sharepoint Services 사용자 지정 기능을 사용하여 팀 공동 작업을 향상시킬 수 있습니다.
보고서	Team System 데이터 웨어하우스에 저장된 정보를 활용하는 SQL 2005 Reporting Services를 사용하여 기존 보고서를 수정하거나 새 보고서를 만들 수 있습니다.
확장성 도구 키트	Visual Studio Team System 확장성 도구 키트를 다운로드하여 확장성 옵션에 대한 자세한 정보를 볼 수 있습니다. 또한 이 도구 키트에는 고유한 테스트 유형을 만드는 방법과 Team System 개체 모델에서 더 광범위한 사용자 지정 옵션을 탐색하는 방법이 나와 있습니다.

결론

Team System이 새로운 제품이며 사실상 소프트웨어 개발 수명 주기의 모든 측면을 지원하는 강력한 도구 집합을 제공한다는 점은 분명한 사실입니다. 다만 Team System을 조직에 적용하는 방법이 분명하지 않을 수 있지만 단순히 도구 집합을 적용한다고 해서 모든 문제가 해결되지는 않는다는 사실을 분명하게 알아야 합니다. Team System이 제공하는 기능은 사용자의 특정 환경에 존재하는 소프트웨어 개발 프로세스의 훨씬 더 광범위한 비전과 조화를 이루어야 합니다. 즉, 조직의 고유한 요구에 충족하는 최상의 방법으로 Team System을 사용해야 합니다.

이 문서의 목적은 특정 기능을 세부적으로 논의하는 것이 아니라 Team System의 여러 영역이 서로 조화되는 방법에 대한 개요를 제공하는 것입니다. Team System의 여러 영역 중에서 관심이 있는 부분은 다른 자료를 통해 좀더 구체적으로 살펴보십시오. 또한 이러한 확장 가능한 통합 도구를 사용하여 소프트웨어 개발 팀에서 좀더 생산적이고 예측 가능한 방식으로 작업을 수행하는 방법에 대해 천천히 시간을 갖고 알아보시기 바랍니다.

Visual Studio Team System에 대한 자세한 내용을 제공하는 재미 있는 블로그가 많이 있지만 초보자라면 먼저 http://blogs.msdn.com/askburton (영문)을 방문하십시오.