프로젝트 계획(CMMI)
프로젝트 계획의 바람직한 결과는 범위, 일정, 예산, 위험 관리 계획, 모든 관련자로부터의 약속 및 동의가 포함된 계획입니다. 합의된 프로젝트 계획이 있으면 분석, 디자인, 개발, 테스트 및 최종 전달을 진행할 수 있습니다.
반복적 개발 방법을 사용하면 위험을 줄일 수 있습니다. 반복을 사용하면 각 반복이 종료될 때 부분적으로 작동하는 제품을 시연하고 시연에서 얻은 피드백에 따라 필요한 조치를 취할 수 있습니다. 따라서 계획 단계에서는 전반적인 개요만 제공하고 각 반복이 시작되기 전에 이를 검토 및 조정합니다.
항목 내용
요구 사항 수집 및 모델링
증분식 제품 요구 사항 작성
제품 요구 사항 입력 및 편집
제품 요구 사항 예측
반복에 제품 요구 사항 할당
테스트 계획
제품 요구 사항 수정
요구 사항 수집 및 모델링
이 활동은 시스템에서 수행해야 하는 작업을 비즈니스 관련자, 예상 사용자 및 실무 전문가와 논의하는 것입니다. 이때 비즈니스 상황을 이해하는 것이 중요합니다. 경찰을 위한 응용 프로그램을 작성하도록 요청 받은 경우 경찰의 전문 용어, 업무 절차 및 규칙을 이해하고 있으면 유용합니다.
UML 모델은 복잡한 관계를 표현하고 숙고하는 데 유용한 도구입니다. Visual Studio에서 UML 모델을 그리고 이를 다른 문서 및 Team Foundation 작업 항목에 연결할 수 있습니다. 자세한 내용은 사용자 요구 사항 모델링을 참조하십시오.
프로젝트 기간 동안 지속적으로 요구 사항 모델을 업데이트하고 조정해야 합니다. 각 반복이 시작될 때가 되면 해당 반복과 관련이 있는 모델 요소에 보다 세부적인 사항을 추가합니다. 모델을 기초로 확인 테스트를 개발할 수 있습니다.
자세한 내용은 Developing Customer Requirements 및 모델에서 테스트 개발을 참조하십시오.
증분식 제품 요구 사항 작성
고객으로부터 수집한 요구 사항을 그대로 사용하여 증분식 개발 일정을 작성할 수는 없습니다. 예를 들어 사용자가 웹 사이트에서 물건을 구입하는 절차를 구체화하기 위해 고객이 카탈로그를 탐색하고, 장바구니에 품목을 추가하고, 장바구니의 합계를 계산하고, 배송 주소를 지정하고, 대금을 결제하면 창고에서 배송 날짜를 결정하는 등의 연속적인 세부 단계를 작성할 수 있습니다. 이러한 단계나 이에 해당하는 동작 다이어그램은 증분식 요구 사항이 아닙니다.
이와 달리, 시스템의 첫 번째 증분에서는 판매 품목을 하나만 제공하고, 이를 한 주소로만 배송하고, 결제 서비스에서는 테스트 거래만 수행하도록 할 수도 있습니다. 두 번째 증분에서는 간단한 목록으로 구성된 카탈로그를 제공하고, 이후의 증분에서는 구입 상품을 선물용으로 포장하거나 다른 업체에서 제공하는 카탈로그를 요청하는 등의 옵션을 추가할 수 있습니다. 또는 단 한 명의 고객만 처리하는 대신 1,000명의 고객을 처리하는 기능과 같이 서비스 품질과 관련된 증분을 작성할 수도 있습니다.
즉, 초기 증분에서는 처음부터 끝까지 주요 사용 사례를 실행해 보고 점진적으로 기능을 추가하여 완성해야 합니다.
기존 제품에 대한 작업을 수행하는 경우에도 원칙은 동일하지만 기존 기능을 토대로 한다는 차이가 있습니다. 내부 디자인에 익숙하지 않은 경우에는 업데이트 비용을 예측하기 어렵습니다. 따라서 초기의 변경 내용에 대한 예상 비용을 넉넉하게 잡아 두는 것이 좋습니다.
자세한 내용은 개발 요구 사항을 참조하십시오.
제품 요구 사항 입력 및 편집
증분식 제품 요구 사항을 Team Foundation에서 요구 사항 작업 항목으로 기록하고, 요구 사항 유형을 기능으로 설정합니다. 팀 탐색기에서 요구 사항 작업 항목을 만들 수 있습니다. 여러 개의 작업 항목을 동시에 만들려는 경우에는 제품 요구 사항 쿼리의 Office Excel 뷰를 사용할 수 있습니다. 자세한 내용은 Team Foundation Server에 연결된 Microsoft Excel 및 Microsoft Project에서 작업 및 Excel에서 작업 항목의 트리 목록을 사용하여 하향식 계획 수행을 참조하십시오.
제품 요구 사항 예측
개발 팀에서는 각 제품 요구 사항을 개발하는 데 필요한 작업을 예측해야 합니다. 예측한 값은 작업 항목의 원래 예상 값 필드에 시간 단위로 입력해야 합니다.
프로젝트 초기에는 대략적인 예측 값만 있으면 됩니다.
큰 제품 요구 사항은 여러 개의 작은 요구 사항으로 나눕니다. 각 제품 요구 사항의 개발 시간은 며칠 정도만 소요하는 것이 이상적입니다.
반복에 제품 요구 사항 할당
비즈니스 관련자의 대표와 개발 팀이 협력하여 반복에 제품 요구 사항을 할당해야 합니다. 이 작업은 일반적으로 회의에서 이루어지며, 회의에서는 제품 요구 사항 쿼리의 Office Excel 뷰를 공유하거나 영사기로 봅니다.
할당은 다음 정보를 사용하여 수행됩니다.
요구 사항의 우선 순위. 다음 하위 단원의 설명을 참조하십시오.
예상 비용. 팀 멤버의 수와 반복 길이가 정해진 경우 각 반복에서 개발에 사용할 수 있는 시간은 고정되어 있습니다. 더욱이 이 시간 중 상당 부분은 반복 계획과 개발에 직접적인 관련이 없는 기타 작업에 소요됩니다.
제품 요구 사항 간의 종속성. 일련의 증분식 요구 사항에서 가장 단순한 요구 사항은 동일한 영역에서 보다 복잡한 요구 사항보다 먼저 처리되어야 합니다.
다음 그림에 나온 것처럼 작업 항목에서 다양한 정보를 지정하여 요구 사항을 정의할 수 있습니다.
.png "요구 사항 작업 항목 폼")
.png "CMMI 요구 사항 작업 항목 폼 - 탭")
우선 순위 지정 지침
우선 순위를 지정하는 데는 여러 가지 세부적인 방식이 있습니다. 반복 계획을 설명할 때 이 중에서 몇 가지를 살펴보겠습니다. 여기서는 프로젝트 수준에서 위험을 관리하고 부가 가치를 최대화하는 데 유용한 몇 가지 지침을 살펴봅니다.
최소한의 종단 간 시나리오에 우선 순위를 두십시오.
프로젝트 초기에는 가능한 한 단순한 종단 간 시나리오를 달성하는 것을 목적으로 합니다. 나중에 시나리오의 여러 부분에 더 많은 기능을 추가합니다. 이 방법을 사용하면 플랫폼의 주요 기능과 요구 사항의 주요 개념을 초기에 시험해 볼 수 있습니다.
반면 일정은 아키텍처에 따라 나누지 마십시오. 데이터베이스, 비즈니스 논리 및 사용자 인터페이스를 순서대로 완료하는 일정의 경우 최종적으로 해당 부분을 통합하기 위한 많은 양의 재작업이 필요할 수 있습니다. 마찬가지로, 판매 구성 요소, 창고 구성 요소 및 결제 구성 요소와 같이 수평적으로 분할하는 방법도 권장되지 않습니다. 이 방법을 사용할 경우 웹 판매를 위한 훌륭한 시스템을 생성할 수 있을지 몰라도 실제 고객 판매를 통한 수입이 생기기까지 너무 많은 시간이 소요될 수 있습니다. 완전한 구성 요소를 후기 반복 일정으로 설정할 수 있는 경우는 해당 구성 요소가 실제로 선택적인 추가 기능인 경우뿐입니다.
기술적 위험에 우선 순위를 두십시오.
시나리오에 기술적으로 위험한 요소가 포함된 경우 해당 요소를 일정 초기에 개발합니다. 실패할 수 있는 경우를 빨리 겪을수록 위험 관리에 유용하기 때문입니다. 달성할 수 없는 요소가 있을 경우 이를 프로젝트 초기에 파악하면 해당 요소를 취소하거나 다른 방법으로 대체할 수 있습니다. 따라서 기술적으로 위험한 요구 사항에 우선 순위를 두어 이를 초기 반복에 포함합니다.
불명확성을 줄이는 작업에 우선 순위를 두십시오.
비즈니스 관련자가 확실히 알지 못하는 요구 사항도 있습니다. 비즈니스 상황에서 어떤 제품 동작이 가장 효과적일지를 예측하기란 어렵습니다. 따라서 불명확성을 줄일 수 있는 작업에 우선 순위를 두십시오. 사용자가 시험해 볼 수 있는 보다 단순한 버전의 시나리오를 개발하면 이를 달성할 수 있는 경우가 많습니다. 이러한 시험 결과를 고려할 수 있는 후기 반복까지 전체 시나리오를 연기합니다.
가치가 높은 요구 사항에 우선 순위를 두십시오.
가능하면 각 시나리오마다 지연으로 인한 기회 비용을 계산하는 함수를 마련합니다. 이를 사용하여 일찍 구현될수록 고객에게 보다 높은 가치를 제공할 수 있는 요구 사항을 파악합니다. 이러한 요구 사항에 우선 순위를 두어 이를 초기 반복에 포함합니다. 이렇게 하면 부분적으로 완료된 제품을 초기에 릴리스할 수 있습니다.
여러 가상 사용자에게 공통적인 시나리오를 그룹화하십시오.
둘 이상의 가상 사용자에게 효용이 있는 시나리오가 있을 경우 이를 그룹화합니다. 그런 다음 해당 시나리오를 필요로 하는 가상 사용자의 수에 따라 그룹화된 시나리오의 순위를 지정합니다. 더 많은 가상 사용자에게 적용되는 시나리오에 우선 순위를 두어 초기 반복에 포함합니다.
가상 사용자의 순위를 지정하십시오.
가상 사용자는 대상 시장 또는 사용자 그룹을 나타냅니다. 마케팅 담당자나 비즈니스 소유자는 전달될 효용이나 대상 시장의 가치에 따라 이러한 대상 시장 또는 사용자 그룹의 우선 순위를 분명히 할 수 있어야 합니다. 우선 순위로 대상 시장 또는 사용자 그룹의 순위를 지정할 수 있으면 각 대상 시장의 가상 사용자를 순위별로 나열하여 이를 표시합니다. 가장 높은 순위가 지정된 가상 사용자의 시나리오를 파악하고, 이 시나리오에 우선 순위를 두어 일정의 초기 반복에 포함합니다.
일반적으로 실패 가능성을 고려하여 위험을 줄이는 데 우선 순위를 둡니다. 일반적인 기능은 반드시 필요하고 변경될 가능성이 적으므로 이러한 기능에 우선 순위를 둡니다. 또한 보다 가치 있는 요구 사항에 우선 순위를 둡니다. 특정한 가상 사용자의 요구를 충족하는 데 필요한 모든 시나리오에 우선 순위를 두어 해당 가상 사용자 집합에 제품을 초기에 릴리스할 수 있도록 합니다.
테스트 계획
각 요구 사항에 대한 예상 작업에는 수동으로 또는 자동화된 테스트를 만들어 요구 사항을 테스트하는 데 필요한 작업이 포함되어야 합니다.
각 제품 요구 사항을 완료된 것으로 간주하려면 먼저 해당 요구 사항이 충족되었는지를 보여 주는 테스트 사례 작업 항목 집합에 요구 사항이 연결되어 있고 테스트가 통과해야 합니다.
제품 요구 사항을 만들거나 수정할 때는 해당 테스트 계획도 업데이트해야 합니다.
제품 요구 사항 수정
각 반복을 시작하기 전에 이 활동을 다시 수행하여 수정되거나 새로 추가된 요구 사항, 수정된 우선 순위 및 수정된 예상 값을 검토하십시오. 초기의 반복에 수정 사항이 더 많을 것입니다.
처음 몇 개의 반복이 종료된 후에는 개발 팀의 멤버가 예상 값을 보다 확신할 수 있게 됩니다. 개발 팀의 멤버는 다음 한두 개의 반복에 대한 예상 값을 검토하고 해당 반복에 할당된 요구 사항의 원래 예상 값 필드를 수정해야 합니다.