프로젝트 활동

아티클
08/15/2011

MSF for CMMI Process Improvement v5.0을 최대한 효율적으로 사용하려면 프로젝트를 일련의 반복되는 단위로 구성해야 하며, 단위는 대개 4-8주입니다. 이렇게 하면 요구 사항 및 구현 비용의 변화로 인한 프로젝트의 위험을 줄일 수 있습니다. 반복적 프로젝트 구조는 CMMI의 위험 관리 요구 사항을 충족하는 데 중요한 역할을 합니다.

CMMI에 대한 자세한 내용은 CMMI의 배경을 참조하십시오.

프로젝트 시작 시 활동

프로젝트 개시

개시 활동에는 프로젝트에서 제품을 릴리스할 때 사용자가 수행할 수 있는 작업에 대해 명시하는 프로젝트 비전 정의가 포함됩니다.

또한 팀, 인프라 및 기타 리소스를 설정하고 개발 프로세스도 결정해야 합니다.

자세한 내용은 초기 프로젝트를 참조하십시오.

초기 프로젝트 계획

프로젝트 계획에는 다음 활동이 포함됩니다.

계획을 세울 수 있도록 요구 사항을 충분히 세부적으로 분석합니다. 이 분석에는 요구 사항 모델 및 스토리보드와 작업 시스템을 파악하는 데 도움을 주는 기타 도구의 사용이 포함될 수 있습니다.
시스템의 전반적인 디자인 또는 아키텍처를 고안합니다. 팀 멤버가 처음 접하는 플랫폼에서의 작업이 필요한 경우 플랫폼을 테스트하기 위한 약간의 시간을 할당해야 합니다. 초기 반복에서는 개발 진행 속도가 느립니다.
요구 사항을 변환하여 대략적인 개발 과정을 평가할 수 있는 일련의 증분식 제품 요구 사항으로 만듭니다. 일반적인 요구 사항과 제품 요구 사항의 차이는 중요하므로 이 과정은 중요한 활동입니다. 자세한 내용은 개발 요구 사항을 참조하십시오.
반복에 대한 제품 요구 사항의 초기 할당을 결정합니다.
릴리스 날짜를 설정합니다.

계획 및 요구 사항 모델은 프로젝트 전체 기간 내내 다시 검토하고 조정합니다. 반복 개발은 초기 단계에서 작동하는 소프트웨어를 시연한 결과에 따라 요구 사항을 개선할 수 있도록 하는 데도 목적이 있습니다.

초기 프로젝트 계획은 반복 0에서 수행됩니다.

자세한 내용은 프로젝트 계획(CMMI)을 참조하십시오.

기존 제품 탐색

프로젝트 목표가 기존의 제품을 업데이트하는 것일 수도 있습니다. 이 경우 팀이 제품에 익숙하지 않으면 반복 0에서 코드 탐색 활동을 수행해야 합니다. 이후 반복의 각 개발 작업에도 특정 위치의 코드를 파악하고 코드 변경 결과를 추적하는 활동이 포함됩니다.

자세한 내용은 기존 코드 시각화을 참조하십시오.

프로젝트 도중 활동

프로젝트 전체 기간 동안 지속적으로 계획을 검토하고 변경해야 합니다.

프로젝트 계획과 관련된 일부 활동은 대개 한 반복의 종료를 목표로 프로젝트 전체 기간 동안 정기적으로 수행됩니다.

유효성 검사

고객이나 비즈니스 관련자에게 반복 동안에 개발된 소프트웨어를 시연합니다. 가능한 경우 고객이나 비즈니스 관련자가 소프트웨어를 살펴보거나 실제 컨텍스트에서 어느 정도 사용해 볼 수 있도록 소프트웨어를 릴리스합니다.

충분히 간격을 둔 후 사용자 피드백을 검토하기 위한 회의를 갖습니다. 이 피드백을 활용하여 변경 요청을 생성해야 합니다.

자세한 내용은 Validating Requirements를 참조하십시오.

위험 관리

부정적인 영향을 줄 수 있는 이벤트의 발생 가능성과 그 영향을 검토하고 위험을 줄이기 위한 단계를 수행합니다. 자세한 내용은 위험 관리를 참조하십시오.

변경 관리

변경 요청 작업 항목을 사용하여 비즈니스 관련자가 명시한 요구 사항에 변경 사항을 기록할 수 있습니다. 이러한 변경 사항은 비즈니스 상황의 변화로 인해 발생할 수도 있지만 초기 버전의 제품을 시연 및 시험한 결과로 발생할 수도 있습니다. 변경을 통해 제품을 비즈니스 목적에 보다 부합하도록 개선할 수 있으므로 이러한 변경 사항은 환영할 만 합니다. 이 효과도 증분식 개발이 노리는 목표의 일부입니다.

프로젝트 팀에서는 변경 요청이 있을 때 별도의 작업 항목을 사용하지 않고 제품 요구 사항 작업 항목을 조정하기도 합니다. 그러나 변경 요청 작업 항목을 사용하면 프로젝트의 이후 단계에서 해당 시점까지 수행된 변경 작업의 수 및 특성을 검토할 수 있다는 장점이 있습니다. 이 정보를 활용하여 이후의 프로세스 또는 아키텍처를 개선할 수 있습니다.

변경 요청은 제품 계획 검토에 대한 입력 정보로 사용해야 합니다.

자세한 내용은 변경 내용 관리(CMMI)를 참조하십시오.

제품 계획 검토

각 반복을 계획하기 전에 제품 계획 검토 단계를 갖습니다. 프로젝트 계획에서는 반복에 제품 요구 사항을 할당합니다.

이 계획은 다음과 같은 두 가지 이유로 변경됩니다.

요구 사항의 변동
개발자가 예측한 사항의 변동. 프로젝트가 진행될수록 개발 팀에서는 이후의 기능을 구현하는 데 필요한 작업을 보다 확실하게 예측할 수 있습니다. 이전 반복에서 일부 기능 요소가 연기되어 계획에 기능이 추가되는 경우도 있습니다.

이후 반복으로 갈수록 두 유형의 변동 모두 빈도가 줄어들게 됩니다.

제품 요구 사항의 기본이 되는 요구 사항 모델을 수정합니다.

반복에 대한 요구 사항 할당을 수정합니다. 초기 계획 활동에서와 마찬가지로 비즈니스 관련자는 우선 순위를 결정하고, 개발 팀은 예측 값을 제공하며, 회의를 통해 반복 간에 기능을 조정합니다.