형상 항목의 상태 변경에 따른 형상 관리
사실 형상 관리의 가장 큰 목적은 변경에 의해 점차적으로 변해가는 소프트웨어의 형상을 관리함에 있다. 형상 항목의 변경은 특정 상태를 거쳐 이뤄지는데 그 흐름을 그림으로 표시하면 <그림 1>과 같다.
형상 항목의 라이프 사이클은 크게 6단계의 상태로 볼 수 있는데 개발 초기에 개발 중이라는 상태에 위치하게 된다. 일단 개발이 어느 정도 완료되면 단위 테스트(unit test)를 준비하고 테스트를 통과하면 시스템 테스트 준비상태로 변하게 된다.
시스템 테스트(system test)도 아무런 이상 없이 통과하면 수락 테스트(acceptance test) 준비상태로 되고 이후 모든 결함(defect)을 제거하면 베이스라인(baseline)을 확정하고 제품을 릴리즈하게 된다. 이때 각 테스트 상태에서 결함이 발견되면 그 전 상태로 돌아가고 발견한 모든 결함을 제거할 때까지 과정을 반복하게 된다.
<그림 1> 형상 관리의 라이프 사이클
(Pankaj Jalote, CMM in Practice, 2000)
앞에서 언급한 형상 관리의 정의에 따라 <그림 1>의 형상 관리 품목의 라이프 사이클을 살펴보면 우선 식별한 형상 항목을 최초로 작성하고 각 테스트를 거치면서 형상 항목을 변경하거나 수정한다. 단위 테스트의 경우 단위 프로그램의 결함 여부를 찾아내는 것이므로 주로 수정의 경우에 해당된다고 할 수 있다.
이 때 개발자가 작성한 프로그램의 경우 결함에 의해 수정되어 버전 통제를 받게 된다. 만약 단위 테스트 결과로 형상 항목의 구성에 포함되어 있다면 프로그램과 해당 단위 테스트의 결과는 서로 관계를 맺고 변경 요청에 의한 변경 통제 프로세스를 따라 진행될 것이다.
단위 테스트를 통과한 단위 프로그램들은 의미 있는 집합으로 묶여 시스템 테스트의 대상이 된다. 이때도 역시 결함이 발견되면 변경 통제 프로세스에 따라 진행한다. 수락 테스트는 주로 소프트웨어의 요구사항과 직접적으로 연관되어 있으므로 변경 통제 절차가 강화되고 요구사항과 변경과의 추적(trace)을 관리해야 한다. 베이스라인 확정 상태는 수락 테스트까지 마친 상태에서 프로젝트 진행 상태의 기준이 되는 아주 중요한 지표가 된다. 한번 확정한 베이스라인은 뒤로 바꿀 수 없다.
프로세스 관점에서 형상 관리 활동
지금까지 형상 항목의 상태에 따른 라이프 사이클을 중심으로 봤다면 이제 프로세스 관점에서 형상 관리 활동을 중심으로 살펴보자. ‘오류! 참조 원본을 찾을 수 없습니다’는 형상 관리 활동을 전반적으로 나타낸 것으로 Anne Mette Jonassen Hass의 『Configuration management principles and practice(2002)』에서 나오는 원래의 그림은 원문자와 곡선 화살표가 없는데 이는 더 용이한 설명을 위해 필자가 첨부한 것이다.
<그림 2> 형상 관리 활동의 개요(Anne Mette Jonassen Hass,
Configuration management principles and practice, 2002)
<그림 2>에서 굵은 선으로 둘러싸인 부분이 형상 관리의 범위이다. 여기에는 형상식별(Identification)과 통제 상에 놓여 있는 저장소(controlled storage), 변경 관리(change control), 상태 보고(status reporting)가 형상 관리의 활동이다. 여기서 형상 감사(audit) 부분은 각종 테스트와 검사에 관계된 활동으로 순수 형상 관리의 활동으로 보기 보다는 품질보증(quality assurance)의 일환으로 보는 관점이 있어 형상 관리의 정의에는 포함되나 그림 상으로는 굵은 선 박스의 외부에 위치시켰다.
그림 상으로 드럼통 모양은 데이터베이스 표식으로 저장소 데이터베이스, 변경 관리 데이터베이스, 메타 데이터베이스가 있다. 이들은 형상 관리를 위한 프로젝트 데이터베이스로 형상 항목의 그 자체를 저장하고(controlled storage), 변경에 관한 이력과 각종 정보를 저장하며(change control), 형상 항목에 대한 이름, 작성자, 생성 날짜와 다른 형상 항목과의 관계를 저장(metadatabase)한다.
그림에서 각 번호는 형상관리 활동을 나타낸 것이다. ①은 형상 관리 계획(configuration management plan)에 따른 형상 식별 활동이다. 우선 프로젝트에서는 프로젝트 계획의 일환으로 작성한 형상 관리 계획을 근거로 형상항목을 식별하여 메타 데이터 베이스에 입력한다. 이때 형상 항목을 유일하게 식별할 수 있도록 형상 항목의 이름, 작성자(author), 생성일, 문서인 경우 문서번호, 다른 형상 항목과의 관계 등을 저장하고 이때부터는 변경 관리의 대상이 된다.
②는 아직 형상 관리 범위 안으로 들어오지 못한 형상 항목의 생성 과정을 나타낸다. 프로덕션(production)은 현재 변경 중인 상태의 항목을 의미한다. 이때까지는 변경 통제의 대상에 포함되지 않는다. ③은 감사를 거쳐 변경할 수 없는 상태의 형상 항목을 구분된 장소에 두는 활동을 의미한다. 이때 보통 테스트를 거치는데 변경 중인 형상 항목과 더 이상의 변경이 없는 항목의 구분을 위해 존재한다. 이 분에서도 역시 변경 통제의 대상에 두지 않는다.
④에서는 ③을 거쳐 나온 항목을 비로소 변경 통제의 대상에 등록하는 활동이다. 이때 누가 왜 무엇을 언제 바꾸었는지 변경관리 데이터베이스에 기록된다. ⑤는 변경 통제 하에 있는 항목의 상태를 리포팅(status reporting)하는 활동이다.
지금까지 형상 관리의 정의와 형상 관리의 대상이 되는 항목의 상태 변화와 형상 관리 활동을 중심으로 살펴보았다. 주로 형상 관리 자체만을 갖고 설명했으므로 피상적이고 따분하겠지만 우선 이런 것이구나 하는 수준으로 접근했으면 한다.
CMM과 형상 관리
여기서 CMM은 정확히 말하자면 SW-CMM으로 소프트웨어 개발 역량을 평가하기 위한 성숙도 모델이다. 여기에는 실제 실행 지침과 소프트웨어 프로세스 개선, 소프트웨어 프로세스 평가를 수행하는 개별 작업자의 요구를 반영한다. 또한 문서화되고 공개적으로 사용 가능하다. CMM의 태동을 주도한 미 국방부의 연구에 따르면 소프트웨어 개발 프로젝트의 성공과 실패를 결정짓는 주요 원인은 기술이라기보다는 관리의 문제라는 결론을 내렸다.
따라서 소프트웨어 개발 조직의 성숙도에 따라 소프트웨어의 품질은 많은 차이를 보인다. 그 이유로는 미성숙한 개발 조직의 경우 소프트웨어의 품질의 좋고 나쁨을 판단하는 객관적인 기준이 없고, 소프트웨어 프로세스가 품질에 어떻게 영향을 미치는지에 대한 이해가 없으며, 정형화된 테스트나 검토와 같은 품질 보증 활동은 이런 저런 이유로 축소되거나 생략된다. 개발팀은 사소한 문제로도 우왕좌왕하고 개인의 역량에 의지하여 해결하려고 한다. 따라서 고객은 최종 인도 이전에는 그들이 사용할 소프트웨어가 어떻게 작동하는지 알 수 없게 된다.
하지만 개발 역량이 성숙한 조직은 프로세스를 적극 활용하여 개발팀이 그들이 맡은 임무에 따라 일사 분란하게 움직이도록 훈련이 되어 있다. CMM은 개발 역량이 성숙한지 아닌지를 평가하기 위해 5단계의 레벨을 두고 있다. 각 레벨의 특징은 <표 1>과 같다.
<표 1> 소프트웨어 프로세스 성숙도의 5레벨
이 5레벨에서 우리가 지금 이야기하고 있는 소프트웨어 형상 관리는 어느 레벨의 인증을 위한 핵심 프로세스에 해당할까? 높은 레벨일 듯 싶지만 겨우 레벨 2이다. 이 정도면 이제 겨우 조직적으로 개발 좀 한다는 소리를 듣는 단계의 시작이다.
CMM에서는 레벨 2에서 소프트웨어 요구사항관리와 함께 형상 관리가 핵심 프로세스 영역(KPA : Key Process Area)으로 되어 있다. 성숙도 레벨에 따른 핵심 프로세스 영역은 <그림 3>과 같다.
<그림 3> 성숙도 레벨에 따른 핵심 프로세스 영역
반복 레벨의 인증을 받기 위해서라도 이것저것 관리해야 할 것이 태산이다. 그 중 CMM이 인정할만한 소프트웨어 형상관리는 어떤 수준인지 살펴보자.
CMM의 형상 관리 가이드
CMU/SEI에서 작성한 『The Capability Maturity Model: Guide for Improving the Software Process, 1st Edition(1994)』을 토대로 CMM이 레벨 2 수준의 형상 관리를 위해서는 목표에 따른 어떠한 수행능력(Ability to Perform)이 있어야 하는지 살펴보자.
[1] 프로젝트 소프트웨어 기준선을 관리할 수 있는 권한을 가진 위원회(즉, 형상통제위원회, SCCB : Software Configuration Control Board)가 존재하거나 없다면 설립한다.
A. 소프트웨어 기준선 결정과 형상 항목 식별 권한을 갖는 의사결정권을 갖는 조직이 결성돼야 한다. 실제 프로젝트 현장에서는 형상 항목의 결정과 변경 통제의 권한을 어떻게 가져가느냐에 많은 신경을 쓰고 있다. 하지만 중요한 것은 의사 결정권을 갖는 역할로 구성돼야 한다는 것이다. 대표적으로 프로젝트 관리자와 고객의 대표로 구성된다.
B. 또한 이 조직은 베이스라인의 승인을 결정하는 중요한 조직으로 형상 관리를 위해서는 반드시 존재해야 한다.
[2] 프로젝트를 위한 SCM의 조정과 구현에 책임을 가진 그룹(즉, SCM 그룹)이 존재한다.
A. 이 그룹은 형상 관리를 위한 모든 활동에 대하여 책임을 갖는다. 이들이 맡고 있는 부분은 앞에서도 언급한 형상 관리의 정의에 해당하는 모든 활동을 책임진다.
i. 프로젝트 소프트웨어 베이스라인 라이브러리 생성과 관리
ii. SCM 계획, 표준, 절차의 개발, 유지 및 분배
iii. SCM 하에 놓인 일련의 작업 산출물 식별
iv. 소프트웨어 베이스라인 라이브러리에 대한 접근 관리
v. 소프트웨어 기준선 갱신
vi. 소프트웨어 기준선 라이브러리로부터 산출물 생성
vii. SCM 작업 기록
viii. SCM 보고서 작성 및 분배
[3] SCM 활동 수행을 위해 적절한 자원과 자금이 지원된다.
A. 여기서 적절한 자원은 형상 관리자의 고유 권한과 책임이 부여돼야 하며
B. 자동화된 형상 관리 도구가 지원돼야 한다.
[4] SCM 그룹의 구성원들은 SCM 활동을 수행하기 위한 목표, 절차, 방법 등에 대해 교육을 받는다.
A. 교육의 범위는 SCM의 표준, 절차, 방법 등이며 형상관리 도구의 사용법과 관리 방법도 숙지해야 한다.
[5] 소프트웨어 엔지니어링 그룹과 다른 소프트웨어 관련 그룹의 구성원들은 SCM 활동을 수행하는 데 필요한 교육을 받는다.
A. 소프트웨어 형상 관리는 비단 SCM 그룹에 국한되는 것이 아니라 프로젝트의 모든 구성원이 어떤 형태로든 참여하게 된다. 따라서 SCM 활동을 위해 준수해야 하는 표준과 절차, 방법을 알아야 하고 형상 관리 도구의 사용법을 숙지해야 한다.
이와 같이 총 5가지의 수행능력을 바탕으로 형상 관리 활동을 실시해야 한다. 어떻게 보면 그야말로 딱딱한 법전 같은 가이드지만 결국 요약하면 프로세스 상에서 권한과 책임을 줘 결정하고 승인할 역할을 만든다. 또한 결정에 따라 형상 관리를 수행할 조직을 만들고, 수행할 사람들에게 교육을 제공해야 한다는 것이다.
너무나 상식적이고 당연한 형상관리
『소프트웨어 공학의 사실과 오해』를 저술한 로버트 L. 글래스는 개발자의 능력에 따라 생산성이 28배까지 차이 난다는 사실을 이야기한바 있다. 어마어마한 수치임에 틀림없다. 실제로 누구나 아는 사실이겠지만 어려운 난관에 부딪히면 초보개발자 100명이 달라붙어도 해결하지 못할 문제를 고급 개발자는 점심시간에 자장면 먹어가며 한 손으로 타이핑 몇 번 만에 해결할 수 있다. 이것은 사실을 넘어서 부인할 수 없는 진실이다.
하지만 조직적으로 소프트웨어를 개발할 때는 어려운 문제만 있는 것이 아니라 해결 가능한 평이한 문제들이 절대 다수를 차지하고 이것들은 서로 관계를 갖고 복잡도를 증가시킨다. 또 끊임없이 변한다.
이렇게 복잡하면서 지속적으로 변하는 소프트웨어라는 괴물을 어떻게 다루는가가 형상 관리의 주된 목적이다. 형상 관리는 반드시 되어야 한다. 그 과정도 너무나 상식적이고 당연하다.@ |
|
