변경 요청(CMMI)
이 항목에서는 변경 요청 작업 항목의 세부 정보를 작성하는 방법에 대해 배울 수 있습니다.팀에서는 변경 요청 작업 항목을 사용하여 제품의 일부 파트에 대해 제안된 변경 내용을 추적할 수 있습니다.변경 제어에서 관리하는 작업 산출물에 대해 변경이 제안될 때마다 변경 요청을 만들 수 있습니다.자세한 내용은 변경 내용 관리(CMMI)을 참조하십시오.
이 작업 항목 형식을 만드는 방법에 대한 자세한 내용은 작업 항목 및 워크플로(CMMI)를 참조하십시오.
항목 내용 |
관련 항목 |
|---|---|
|
프로세스 지침 통합 문서 필드 참조 |
필요한 권한
변경 요청을 보려면 Readers 그룹의 멤버이거나 이 노드의 작업 항목 보기 권한이 허용으로 설정되어 있어야 합니다.변경 요청을 수정하려면 Contributors 그룹의 멤버이거나 이 노드의 작업 항목 편집 권한이 허용으로 설정되어 있어야 합니다.자세한 내용은 권한 관리을 참조하십시오.
변경 요청 정의
변경 요청에 대한 작업 항목 폼은 다음 그림에 나오는 필드와 탭에 데이터를 저장합니다.
.png "변경 요청 작업 항목 폼")
변경 요청을 정의할 때는 제목을 정의해야 합니다.다른 모든 필드는 비워 두거나 기본값을 적용할 수 있습니다.
단일 변경 요청을 정의하려면
작업 항목 폼의 최상위 섹션에서 다음 정보 유형 중 하나 이상을 지정합니다.
제목(필수)에 간단한 설명을 입력합니다.
제목에는 영향을 받는 제품 영역과 어떤 방식으로 영향을 받는지를 나타내는 것이 좋습니다.언제든지 텍스트를 업데이트하여 변경 및 영향을 받는 작업 영역을 보다 정확하게 정의할 수 있습니다.
에 할당 목록에서 변경 요청을 처리할 책임이 있는 팀 멤버의 이름을 선택 합니다.
[!참고]
작업 항목은 Contributors 그룹의 멤버에게만 할당할 수 있습니다.
변경 요청 담당자를 지정하지 않으면 자동으로 자신에게 할당됩니다.
상태 목록에서 기본값 제안됨을 그대로 둡니다.
이유 필드의 기본값은 신규입니다.이 필드에 대한 설명 및 이 필드를 사용하여 워크플로를 추적하는 방법에 대한 자세한 내용은 이 항목의 뒷부분에 나오는 변경 요청 상태 변경을 참조하십시오.
에 우선 순위 목록에서 수준 1 (가장 중요) 4 (가장 중요) 중 변경 요청에 대 한 중요도 선택 합니다.
기본값은 2입니다.
에 심사 목록에서 심사 하위 상태를 선택 합니다.
이 필드는 제안됨 상태의 변경 요청에 대해 결정된 심사 수준을 식별합니다.유효한 값은 보류 중(기본값), 추가 정보, 받은 정보 및 심사됨입니다.
에 차단 된 목록에서 선택 예 문제는 팀에서 변경 요청을 구현 되지 않도록 하는 경우.
에 영역 및 반복 목록에서 적절 한 영역과 반복을 선택 합니다.
[!참고]
프로젝트 관리자가 영역 및 반복 트리 계층을 정의했으므로 팀 멤버는 이러한 지정을 통해 진행률을 추적할 수 있습니다.자세한 내용은 영역 및 반복 만들기 및 수정을 참조하십시오.
에 정보 탭에서 팀을 변경 해야 정확 하 게 무엇을 설명 하려는 최대한 자세하게 설명 합니다.
변경 요청을 개발자가 구현할 수 있고 테스터가 테스트할 수 있도록 최대한 자세하게 입력합니다.팀에서 이 정보를 사용하여 작업 및 테스트 사례를 위한 작업 항목을 만들 수 있습니다.자세한 내용은 작업(CMMI) 및 테스트 사례(Agile)를 참조하십시오.
에 맞춤 탭에서 원하는 고객 또는 제품 변경 요청을 구현 하는 값을 설명 하려면 최대한 자세하게 설명 합니다.
에 분석 탭, 각 텍스트 상자를 선택 하 고 변경 요청이 다음 영역에 미칠 영향에 대 한 정보를 제공 합니다.
아키텍처에 미치는 영향
사용자 경험에 미치는 영향
테스트에 미치는 영향
디자인/개발에 미치는 영향
기술 문서화에 미치는 영향
변경을 구현하기 위한 비용 외에 영향을 받는 특정 영역도 나타낼 수 있습니다.
에 기타 탭에서 다음 정보 유형을 지정 합니다.
원래 예상 값 상자에 변경 요청을 구현하는 데 필요한 작업 시간을 나타내는 값을 입력합니다.
[!참고]
일반적으로 다음 필드는 변경 요청을 처음으로 정의할 때가 아니라 개발 주기의 후반부에서 정의합니다.
에 통합 목록에서 선택 빌드 이름 또는 번호 변경 요청 개발 팀으로 통합 됩니다.
에 모든 링크 탭을 하나 이상의 다른 작업 항목, 요구 사항 또는 작업과 같은 변경 요청 링크.
에 첨부 파일 탭을 첨부할 수 있습니다 사양, 이미지 또는 기타 파일 구현 하기 위해 변경 요청에 대 한 자세한 정보를 제공 합니다.
자세한 내용은 이 항목의 뒷부분에 있는 다음 단원을 참조하십시오.
요구 사항, 작업 또는 기타 작업 항목에 변경 요청 연결
변경 요청에 세부 정보, 첨부 파일 또는 하이퍼링크 추가
선택
.png "저장")
작업 항목 저장.[!참고]
변경 요청을 저장하면 작업 항목 도구 모음 아래의 제목에 식별자가 나타납니다.
요구 사항, 작업 또는 기타 작업 항목에 변경 요청 연결
변경 요청과 다른 작업 항목 간에 관계를 만들면 프로젝트를 더 효과적으로 계획하고, 종속성을 더 정확하게 추적하고, 계층적 관계를 더 명확하게 표시하고, 관련 정보를 더 빠르게 찾을 수 있습니다.변경 요청의 작업 항목 폼에서 변경 요청에 자동으로 연결되는 작업 항목을 만들거나, 기존 작업 항목에 대한 링크를 만들 수 있습니다.
링크 탭을 사용하여 특정 작업 항목 형식에 대한 특정 링크 형식을 만듭니다.자세한 내용은 Linking Work Items (CMMI)을 참조하십시오.
작업, 버그, 요구 사항 또는 기타 작업 항목을 만들고 변경 요청에 연결하려면
변경 요청 작업 항목 폼을 열고는 모든 링크 탭을 클릭 한 다음 선택
.png "링크된 새 작업 항목 추가")
New.링크된 새 작업 항목 추가 대화 상자가 열립니다.
.png "링크된 새 작업 항목 추가 대화 상자")
에 링크 형식 목록에서 연결 된 작업 항목의 종류에 따라 원하는 링크 유형을 선택 합니다.
작업이나 버그에 연결하려면 자식 링크를 만듭니다.
요구 사항, 위험 또는 문제에 연결하려면 영향을 받음 링크를 만듭니다.
테스트 사례에 연결하려면 테스트한 사람 링크를 만듭니다.
다른 작업 항목 형식에 연결하려면 관련 링크 또는 추적할 관계를 나타내는 다른 링크 형식을 만듭니다.
에 작업 항목 형식 목록에서 만들려는 작업 항목의 형식을 선택 합니다.
제목에 제안된 변경에 대해 명확하게 알 수 있는 설명을 짧게 입력합니다.
(선택 사항) 설명에 추가 정보를 입력합니다.
확인을 선택합니다.
지정된 작업 항목의 형식에 대한 작업 항목 폼이 제공된 정보와 함께 열립니다.
다음 항목에 설명된 대로 나머지 필드를 지정합니다.
선택
작업 항목 저장.
변경 요청에 기존 작업 항목을 여러 개 연결하려면
변경 요청 작업 항목 폼을 열고는 모든 링크 탭을 클릭 한 다음 선택
.png "링크 추가")
링크를.변경 요청에 대한 링크 추가 대화 상자가 열립니다.
.png "요구 사항에 대한 링크 추가 대화 상자")
에 링크 형식 목록에서 연결 된 작업 항목의 종류에 따라 원하는 링크 유형을 선택 합니다.
작업이나 버그에 연결하려면 자식 링크를 만듭니다.
요구 사항, 위험 또는 문제에 연결하려면 영향을 받음 링크를 만듭니다.
테스트 사례에 연결하려면 테스트한 사람 링크를 만듭니다.
다른 작업 항목 형식에 연결하려면 관련 링크 또는 추적할 관계를 나타내는 다른 링크 형식을 만듭니다.
다음 작업 중 하나를 수행합니다.
작업 항목 ID에 찾을 작업 항목의 ID를 입력합니다.쉼표나 공백을 사용하여 ID를 구분합니다.
선택 찾아보기 목록에서 작업 항목을 지정 합니다.
링크된 작업 항목 선택 대화 상자가 나타납니다.
.png "링크된 작업 항목 선택 대화 상자")
에 저장 된 쿼리 목록에서 추가 하려는 작업 항목을 포함 하는 쿼리를 선택 합니다.선택할 수 있습니다 예를 들어, 열려 있는 작업 항목, 활성 버그, 또는 활성 작업.
선택 찾기, 변경 요청에 연결 하 고 선택 하려는 각 작업 항목 옆의 확인란을 선택 합니다. 확인.
(선택 사항) 연결할 항목에 대한 설명을 입력합니다.
확인을 선택합니다.
자세한 내용은 연결하거나 가져올 작업 항목 찾기을 참조하십시오.
선택
작업 항목 저장.[!참고]
변경 요청 및 변경 요청이 연결된 작업 항목이 둘 다 업데이트됩니다.
변경 요청에 세부 정보, 첨부 파일 또는 하이퍼링크 추가
더 많은 정보를 사용할 수 있게 되면 다음과 같은 방법으로 변경 요청에 정보를 추가할 수 있습니다.
정보, 근거 또는 분석 탭의 텍스트 상자에 정보를 입력합니다.
파일을 첨부합니다.
예를 들어 전자 메일 스레드, 문서, 이미지, 로그 파일 또는 기타 형식의 파일을 첨부할 수 있습니다.
서버나 웹 사이트에 저장된 파일 또는 웹 사이트에 대한 하이퍼링크를 추가합니다.
변경 요청에 세부 정보를 추가하려면
선택은 정보, 맞춤, 또는 분석 탭 및 형식 정보 상자에.
정보에 서식을 지정하여 강조하거나 글머리 기호 목록을 표현할 수 있습니다.
[!참고]
팀 멤버가 작업 항목을 업데이트할 때마다 작업 항목 기록에 변경 날짜, 변경한 팀 멤버 이름 및 변경된 필드가 표시됩니다.
자세한 내용은 변경 요청 필드 참조(CMMI) 및 요구 사항 필드 참조(CMMI)를 참조하십시오.
선택
작업 항목 저장.
변경 요청에 첨부 파일을 추가하려면
첨부 파일 탭에서 다음 작업 중 하나를 수행합니다.
파일을 첨부 파일 영역으로 끕니다.
선택
.gif "붙여넣기")
또는 복사한 파일을 붙여 넣으려면 CTRL + V를 누릅니다.선택
.png "첨부 파일 추가")
추가, 선택 찾아보기, 및에 첨부 파일 대화 상자, 형식 또는 첨부 파일의 이름 찾습니다.(선택 사항) 설명 상자에 첨부 파일에 대한 추가 정보를 입력합니다.닫을 수 있는 첨부 파일 대화 상자에서 선택 확인.
선택
작업 항목 저장.
변경 요청에 하이퍼링크를 추가하려면
에 모든 링크 탭에서 선택
링크를..png "하이퍼링크 주소의 URL 지정")
에 링크 형식 목록에서 선택 하이퍼링크.
주소 상자에서 다음 작업 중 하나를 수행합니다.
대상이 웹 사이트인 경우 URL을 입력하거나, 인터넷 브라우저에서 URL을 복사하여 주소 상자에 붙여넣습니다.
대상이 서버 위치인 경우 UNC 주소를 입력합니다.
(선택 사항) 설명 상자에 하이퍼링크에 대한 추가 정보를 입력합니다.
확인을 선택합니다.
선택
작업 항목 저장.
변경 요청의 상태 변경
심사 팀 또는 제품 계획 회의에서는 이러한 작업 항목을 검토하여 제안된 변경을 분석한 후 승인하거나 거부할 수 있습니다.변경 요청이 승인되면 팀에서 해당 변경을 구현하기 위한 작업을 생성할 수 있습니다.팀에서 변경을 구현한 후에는 변경 요청을 닫습니다.
작업 항목 상태를 추적하는 데 사용할 수 있는 데이터 필드에 대한 자세한 내용은 할당, 워크플로 및 계획(CMMI)을 참조하십시오.
다음과 같은 상태를 사용하여 변경 요청의 진행률을 추적할 수 있습니다.
제안됨
Active
해결됨
완료
모든 팀 멤버가 변경 요청의 상태를 변경할 수 있습니다.
기본적으로 각 변경 요청 작업 항목을 만들면 제안됨 상태로 설정됩니다.팀에서 현재 반복에 대한 변경 요청을 승인하면 이 작업 항목이 활성 상태로 전환되고, 팀은 작업 항목을 분석하여 구현 정보를 확인한 후 작업을 만듭니다.작업이 완료되고 시스템 테스트 결과 변경 요청이 성공적으로 구현되었으면 팀 멤버가 변경 요청을 해결됨 상태로 전환합니다.마지막으로 팀에서 변경 요청의 유효성을 검사하면 팀 멤버가 변경 요청을 닫힘 상태로 전환합니다.
변경 요청의 상태를 변경하려면
변경 요청을 엽니다.
에 상태 목록에서 선택 활성, "해결 됨", 또는 닫힌.
상태를 제안됨에서 활성으로 변경하면 이유 필드가 자동으로 승인됨으로 변경됩니다.
상태를 활성에서 해결됨으로 변경하면 이유 필드가 자동으로 코드 완료 및 시스템 테스트 성공으로 변경됩니다.
상태를 해결됨에서 닫힘으로 변경하면 이유 필드가 유효성 검사 테스트 성공으로 변경됩니다.
선택
작업 항목 저장.
일반적인 워크플로 진행:
일반적이 아닌 전환:
|
변경 요청 상태 다이어그램 .png "변경 요청의 워크플로")
|
.gif "Ee332482.collapse_all(ko-kr,VS.110).gif")
제안됨(신규)
팀에서 버그를 찾는 경우 또는 다른 이벤트를 실행한 결과 변경 제어에서 관리하는 작업 산출물에서 필요한 변경을 식별하는 경우 팀 멤버가 변경 요청 작업 항목을 만들 수 있습니다.
팀 멤버가 변경 요청을 만들면 다음 데이터 필드가 자동으로 캡처됩니다.
만든 사람: 변경 요청을 만든 팀 멤버의 이름입니다.
만든 날짜: 변경 요청이 만들어진 날짜 및 시간이며 서버 시계를 기준으로 기록됩니다.
제안됨 상태에서 활성 상태로
변경 요청은 제품 또는 기준에 대한 변경 내용을 기술합니다.변경 제어 위원회는 팀에서 제안하는 각 변경 내용을 검토하고 조사한 후 승인하거나 거부해야 합니다.
팀 멤버는 다음 표에 기술된 이유로 변경 요청을 제안됨 상태에서 활성 상태로 전환할 수 있습니다.
이유 |
용도 |
수행할 추가 작업 |
|---|---|---|
승인됨 |
팀이 현재 반복에서 구현할 수 있도록 변경 제어 위원회에서 변경 요청을 승인하는 경우 |
구현을 담당할 팀 멤버에게 변경 요청을 할당합니다. |
확인 |
변경 제어 위원회에서 변경 요청을 승인하기 전에 해당 요청의 영향을 확인해야 한다고 판단하는 경우 |
확인이 완료되면 변경 요청을 제안됨 상태로 되돌립니다. |
팀 멤버가 변경 요청의 상태를 활성으로 변경하면 다음 데이터 필드가 캡처됩니다.
활성화한 사람: 변경 요청을 활성화한 팀 멤버의 이름입니다.
활성화된 날짜: 변경 요청이 활성화된 날짜 및 시간이며 서버 시계를 기준으로 기록됩니다.
상황 변경 날짜: 변경 요청의 상태가 변경된 날짜 및 시간입니다.
제안됨 상태에서 닫힘 상태로
팀 멤버는 다음 표에 기술된 이유로 인해 제안됨 상태의 변경 요청을 닫을 수 있습니다.
이유 |
용도 |
수행할 추가 작업 |
|---|---|---|
거부됨 |
변경 제어 위원회가 팀에서 요청을 구현할 수 없거나 고객에게 필요하지 않다고 판단하는 경우 |
없음 |
팀 멤버가 변경 요청을 닫으면 다음 데이터 필드가 캡처됩니다.
닫은 사람: 변경 요청을 닫은 팀 멤버의 이름입니다.
닫힌 날짜: 변경 요청이 닫힌 날짜 및 시간이며 서버 시계를 기준으로 기록됩니다.
상황 변경 날짜: 변경 요청의 상태가 변경된 날짜 및 시간입니다.
Active
팀에서는 활성 상태의 변경 요청만 구현해야 합니다.활성 변경 요청에 대해 팀 멤버는 코드 작성, 테스트 및 변경 문서화 작업을 만들어야 합니다.모든 작업이 완료되면 팀 멤버는 변경 요청을 해결됨 상태로 전환합니다.팀에서 중단하거나 범위를 벗어나는 것으로 판단하면 해당 변경 요청을 닫을 수도 있습니다.
활성 상태에서 해결됨 상태로
팀 멤버는 다음 표에 기술된 이유로 활성 변경 요청을 해결할 수 있습니다.
이유 |
용도 |
수행할 추가 작업 |
|---|---|---|
코드 완료 및 시스템 테스트 완료 |
팀에서 변경 요청을 구현할 코드를 체크 인했고 모든 시스템 테스트를 통과한 경우 |
테스트를 담당할 팀 멤버에게 변경 요청을 할당합니다. |
팀 멤버가 활성 변경 요청을 해결하면 다음 데이터 필드가 캡처됩니다.
해결한 사람: 변경 요청을 해결한 팀 멤버의 이름입니다.
해결된 날짜: 변경 요청이 해결된 날짜 및 시간이며 서버 시계를 기준으로 기록됩니다.
상황 변경 날짜: 변경 요청의 상태가 변경된 날짜 및 시간입니다.
활성 상태에서 닫힘 상태로
팀 멤버는 다음 표에 기술된 이유 중 하나로 인해 활성 변경 요청을 닫을 수 있습니다.
이유 |
용도 |
수행할 추가 작업 |
|---|---|---|
중단됨 |
변경 요청을 더 이상 구현할 필요가 없다고 판단되는 경우 |
없음 |
범위를 벗어남 |
팀에서 리소스가 충분하지 않거나 다른 문제로 인해 현재 반복에 대해 변경 요청을 구현할 수 없는 경우 |
반복 필드를 업데이트하여 팀에서 변경 요청을 구현할 수 있는 반복을 지정합니다.변경 요청이 소프트웨어의 다음 릴리스로 연기될 경우에는 반복 필드를 비워 둡니다. 이때 변경 요청이 연기된 이유와 팀에서 변경 요청을 구현할 시기 등에 대해 자세히 기술합니다. |
팀 멤버가 활성 변경 요청을 닫으면 다음 데이터 필드가 캡처됩니다.
닫은 사람: 변경 요청을 닫은 팀 멤버의 이름입니다.
닫힌 날짜: 변경 요청이 닫힌 날짜 및 시간이며 서버 시계를 기준으로 기록됩니다.
상황 변경 날짜: 변경 요청의 상태가 변경된 날짜 및 시간입니다.
활성 상태에서 제안됨 상태로
변경 요청이 확인으로 활성화된 경우에는 팀이 확인 작업을 완료한 후 변경 요청의 상태를 제안됨으로 변경합니다.활성 변경 요청의 상태를 제안됨으로 변경하면 다음 데이터 필드가 캡처됩니다.
변경한 사람: 변경 요청의 상태를 변경한 팀 멤버의 이름입니다.
상황 변경 날짜: 변경 요청의 상태가 변경된 날짜 및 시간입니다.
해결됨
팀에서 변경 요청을 구현한 후에는 수석 개발자가 요청의 상태를 해결됨으로 설정하고, 테스트를 시작할 수 있도록 테스터에게 변경 요청을 할당합니다.
해결된 변경 요청이 구현되었고 시스템 테스트를 통과합니다.그러나 팀에서 고객의 기대에 따라 요청을 구현했음을 확인하기 위해 고객과 함께 해결된 변경 요청의 유효성을 검사해야 합니다.유효성 테스트를 통과하면 팀에서 변경 요청을 닫고,그렇지 않으면 추가 작업을 위해 변경 요청이 다시 활성화됩니다.
해결됨 상태에서 닫힘 상태로
팀 멤버는 다음 표에 기술된 이유로 해결됨 상태의 변경 요청을 닫을 수 있습니다.
이유 |
용도 |
수행할 추가 작업 |
|---|---|---|
유효성 검사 테스트 성공 |
변경 요청이 모든 유효성 검사 테스트를 통과한 경우 |
제품 소유자에게 변경 요청을 할당합니다. |
팀 멤버가 해결된 변경 요청을 닫으면 다음 데이터 필드가 자동으로 캡처됩니다.
닫은 사람: 변경 요청을 닫은 팀 멤버의 이름입니다.
닫힌 날짜: 변경 요청이 닫힌 날짜 및 시간이며 서버 시계를 기준으로 기록됩니다.
상황 변경 날짜: 변경 요청의 상태가 변경된 날짜 및 시간입니다.
해결됨 상태에서 활성 상태로
팀 멤버는 다음 표에 기술된 이유로 해결됨 상태의 변경 요청을 다시 활성화할 수 있습니다.
이유 |
용도 |
수행할 추가 작업 |
|---|---|---|
유효성 검사 테스트 실패 |
하나 이상의 유효성 검사 테스트에서 충족되지 않는 고객 기대가 하나 이상 있는 것으로 나타나는 경우 |
테스터가 테스트 실패에 대한 버그를 만들고, 문제 해결 방법을 결정하는 수석 개발자에게 변경 요청을 할당합니다. |
팀 멤버가 해결됨 상태의 변경 요청을 다시 활성화하면 다음 데이터가 자동으로 캡처됩니다.
활성화한 사람: 변경 요청을 다시 활성화한 팀 멤버의 이름입니다.
활성화된 날짜: 변경 요청이 다시 활성화된 날짜 및 시간이며 서버 시계를 기준으로 기록됩니다.
상황 변경 날짜: 변경 요청의 상태가 변경된 날짜 및 시간입니다.
완료
팀은 닫힌 변경 요청에 대해 더 이상 작업하지 않아야 합니다.변경 요청은 변경 제어 위원회에서 거부한 경우 또는 팀에서 요청에 대한 구현, 확인 및 유효성 검사 작업을 성공적으로 수행한 경우 닫힘 상태로 설정됩니다.
닫힌 변경 요청이 다시 범위 안에 들어오면 팀 멤버 중 주로 비즈니스 분석가나 프로그램 관리자가 이 변경 요청을 다시 활성화할 수 있습니다.
닫힘 상태에서 활성 상태로
팀 멤버는 다음 표에 기술된 이유로 닫힘 상태의 변경 요청을 다시 활성화할 수 있습니다.
이유 |
용도 |
수행할 추가 작업 |
|---|---|---|
실수로 닫힘 |
팀 멤버가 실수로 변경 요청을 닫은 경우 |
변경 요청에 대한 구현 작업, 테스트 사례 및 세부 정보가 제대로 정의되었고 개발을 충분히 지원할 수 있는지 확인합니다. |
팀 멤버가 닫힘 상태의 변경 요청을 다시 활성화하면 다음 데이터가 자동으로 캡처됩니다.
활성화한 사람: 변경 요청을 다시 활성화한 팀 멤버의 이름입니다.
활성화된 날짜: 변경 요청이 다시 활성화된 날짜 및 시간이며 서버 시계를 기준으로 기록됩니다.
상황 변경 날짜: 변경 요청의 상태가 변경된 날짜 및 시간입니다.
참고 항목
개념
Visual Studio ALM에 대한 작업 항목 필드 참조