가) 목적
형상 및 변경 관리 웍플로우의 목적은 프로젝트 진행과정에서 변화하는 프로젝트 자산의 무결성을 추적 유지하는 것이다. 개발주기 동안에 많은 가치 있는 산출물들이 생성된다. 이러한 산출물을 생성하는 데에는 많은 노력이 투입되고 따라서 가치 있는 투자 대상으로 생각할 수 있다. 그렇기 때문에 이러한 산출물은 보호되어야 하며 쉽게 재사용될 수 있어야 한다. 또한 이러한 산출물은 반복적인 개발과정에서 계속해서 발전되고 계속해서 업그레이드된다. 산출물을 담당하는 작업자가 있지만 사람의 기억에 의존하여 이러한 소중한 자산을 관리하는 것은 위험한 일이다.
프로젝트 팀원은 산출물을 식별하고 접근할 수 있어야 한다. 이를 통해 알맞은 버전의 산출물을 선택할 수 있고, 산출물의 현재상태와 변경 사유를 설명한 변경이력을 볼 수 있으며, 현재 누가 산출물에 대한 책임을 지고 있는가를 파악할 수 있다. 동시에 프로젝트 팀은 제품의 발전과정을 추적하고, 다양한 곳으로부터 발생하는 변경요구를 수집하여 관리하고, 일관성 있게 산출물에 변경요구를 구현할 수 있어야 한다. 또한, 프로젝트 관리 웍플로우를 지원하기 위해 중요한 프로젝트 산출물에 대한 상태정보를 제공해야 하고 주요 산출물의 변경에 관련된 평가기준을 수집해야 한다.
나) 작업자와 산출물
형상 및 변경 관리 웍플로우의 주요 작업자는 다음과 같다.
- 프로젝트 관리자(Project Manager) : 전체 소프트웨어 개발 계획(SDP)의 한 요소인 형상 관리 계획에 대한 책임이 있다.
- 형상 관리자(Configuration Manager) : 개발과 통합을 위한 작업공간(Workspace)을 정의하고 할당하는 것을 포함한 형상관리 시스템 구축에 대한 책임을 진다(형상 관리 시스템을 구축할 때에는 개발하는 시스템의 구조를 적절히 반영해야 한다.). 또한 형상 관리자는 프로젝트 관리자를 위해 상태 및 평가 보고서를 작성한다..
다음과 같은 작업자도 형상 및 변경 관리 웍플로우에 관련되어 있다.
- 구현 담당자(Implementer) : 자신이 맡은 변경 사항을 구현하기 위해 필요한 산출물과 작업공간을 이용한다.
- 통합 담당자(Integrator) : 통합 작업공간에서 변경 사항을 수용하여 제품을 빌드한다.
- 임의의 작업자(any worker) : 변경 요구를 제출할 수 있다.
- 아키텍트 : 구현 관점(Implementation View)을 통해 개발하는 시스템의 구조에 대한 정보를 제공한다.
변경 제어 위원회(Change Control Board:CCB)는 프로젝트 관리자, 아키텍트, 형상 관리자, 고객 대표, 마켓팅 담당자 등과 같은 기술 및 관리적으로 관심을 갖는 다양한 인원으로 구성된 그룹이다. CCB의 역할에는 변경의 영향 평가, 우선순위 결정, 변경 승인 등이 있다.
형상 및 변경 관리의 주요 산출물에는 다음과 같은 것이 있다.
- 형상관리 계획(Configuration Management Plan : CM Plan) : 형상관리 계획은 버전 관리, 작업공간 관리, 변경요구 관리, 빌드, 릴리즈와 같은 프로젝트의 형상관리 작업에 사용할 정책 및 실무를 기술한다.
- 변경 요구(Change Requests) : 변경 요구는 문서상의 결함, 요구사항의 변경, 소프트웨어의 버그 등 매우 다양한 형태를 갖는다. 모든 변경 요구에는 제출자와 원인에 대한 정보가 포함된다. 추후의 영향 분석(Impact Analysis)은 연관된 산출물, 비용, 스케쥴 등의 관점으로 변경의 영향을 첨부한다. 변경 요구는 작업이 진행됨에 따라 상태가 변경된다. 이력 정보(특히 변경제어 위원회(CCB)의 결정사항)는 변경 요구에 첨부되어 관리된다.
또한 다음과 같은 산출물도 형상 및 변경 관리 웍플로우에 포함된다.
- 구현 모델(Implementation Model) : 형상관리자가 형상관리 환경을 구축하기 위해 필요한 개발하는 제품에 대한 정보를 제공한다.
- 평가기준 및 상태 보고서(Metrics and Status Reports) : 상태 평가 보고서는 CM과 CRM 지원 환경으로부터 정보를 추출하여 작성한다.
다음 그림은 형상 및 변경 관리 웍플로우에서 작업자와 산출물의 관계를 보여준다.
다) 웍플로우
형상 및 변경 관리에는 두개의 서로 밀접한 관계를 갖는 웍플로우가 있다. 하나는 형상관리 측면의 웍플로우이고 다른 하나는 변경 요구 관점의 웍플로우이다. 형상 관리 측면에서의 웍플로우는 다음과 같다.
- 프로젝트 관리자는 프로젝트에 사용될 구체적인 CM 실무를 정립하여 CM 계획을 작성한다.
- 소프트웨어 아키텍처 문서(구현 관점 : Implementation View)의 정보에 기반하여 형상 관리자는 제품 구조를 확립하고, 개발자와 통합자에게 필요한 다양한 작업공간을 생성하여 할당한다.
- 작업자는 자신의 작업 공간에 접근하여 산출물을 수정한다. 특히, 자신에게 할당된 변경 요구를 구현한다.
- 통합자는 통합 작업공간에서 변경을 수용하여 제품을 빌드한다. 빌드한 제품은 테스트 대상이 된다.
- 새로운 기준버전(baseline)이 반복의 끝에서 생성된다.
형상관리 측면에서 바라본 형상 및 변경 관리 웍플로우
변경 요구의 관점에서 본 웍플로우는 약간 달라진다.
- 변경 요구 입력
- 변경 요구가 산출물, 비용, 스케쥴에 미치는 영향을 분석한다.
- 변경제어 위원회(CCB)는 영향 분석, 변경된 우선순위를 검토하여 변경요구를 승인한다.
- 변경 요구를 구현을 위해 작업자에 할당한다.
- 변경 사항을 새로운 빌드에 통합하여 테스트한다.
- 변경 요구가 종료
라) 도구 지원
모든 변경을 관리하는 것은 대단히 어렵다. 변경 요구를 정확히 관리하는 것의 어려움은 시간이 지날수록, 팀의 크기가 커질수록, 제품의 크기(즉, 산출물의 수)가 커질수록, 팀이 지리적으로 분산되어 있을수록, 일정이 촉박할수록 기하급수적으로 커진다. 이처럼 변경요구 관리는 오류가 발생하기 쉽고, 많은 인적자원이 소모되는 작업이므로 도구의 지원을 통한 자동화로서 많은 이익을 얻을 수 있다. 래쇼날은 형상 및 변경 관리 웍플로우를 다음의 도구를 통해 지원한다.
- ClearCase는 형상 관리를 지원한다.
- ClearQuest는 변경 요구 관리와 프로젝트의 상태 평가를 지원한다.
마) 요약
- 형상 및 변경 관리 웍플로우의 목적은 변경요구를 처리하면서 발전(evolve)하는 과정에서 프로젝트 산출물의 무결성을 유지하는 것이다.
- 형상관리는 제품의 구조, 구성요소의 식별, 구성요소의 유효한 형상, 그리고 작업공간을 다룬다.
- 변경요구 관리는 일관성 있게 산출물을 변경하는 프로세스를 포함한다.
- 상태와 상태 평가에 도움이 되는 평가기준(metrics)은 형상과 변경 관리 정보로부터 추출할 수 있다.
- ClearCase와 ClearQuest같은 도구는 형상 및 변경 관리 웍플로우의 단조로운 작업 대부분을 자동화한다.
본 글의 모든 저작권은 Rational에 있습니다.
'아키텍처와 공학' 카테고리의 다른 글
RUP Core workflows[9] 배포 웍플로우 (0) | 2009.10.26 |
---|---|
RUP Core workflows[8] 환경 웍플로우 (0) | 2009.10.26 |
RUP Core workflows[6] 테스트 웍플로우 (0) | 2009.10.26 |
RUP Core workflows[5] 구현 웍플로우 (0) | 2009.10.26 |
RUP Core workflows[4] 분석 & 설계 웍플로우 (0) | 2009.10.26 |