이야기를 시작하며...
오래전부터 관심이 있던 부분인데, 프로젝트의 작업환경과 관리자의 마인드가 여건이 되지 않아 이부분만 현장에 적용한 것들이 많다. 형상관리를 좀더 잘 활용하면 기존 생성부분을 재활용함으로써 소프트웨어 개발단가를 낮출 수 있음에도 불구하고 기술적/비용적인 문제로 시도가 되지 않고 있는 것이 현실이다. 아직도 많은 프로젝트가 재활용없이 신규로 작성되는 부분이 많다. 비교적, 웹시스템 구축은 재활용이 많으나 이 경우도 관리가 제대로 되지 않아서 중복관리되는 경우가 많이 있다.
개인적으로 미국의 형상관리시스템을 프로젝트 관계로 10여년 전에 접했는데 당시로는 대단한 충격이었다. 재활용 차원이 아닌 모든 자료(문서포함)를 관리하며, 효율적으로 관리 소프트웨어를 운영하는 것을 보고 CMM을 형식적으로 운영하는 것이 아닌 활용하고 있다는 생각에 참 부럽다는 생각이 많았다.
아시다시피 CMM이나 SPICE에도 형상관리 항목은 있으나 매우 작은 부분이라 형식적으로만 수행하면 통과되는 것이기에 당시 많은 한국회사들이 CMM 심사통과 목적으로 형식적인 형상관리를 수행하였고, 형상관리의 정확한 개념을 이해하는 분드로 그리 많지 않았다. 기술적으로도 개발된 소스를 관리해 보았자 이를 시스템에 재활용되는 경우는 극히 저조했기에 재활용은 문서만을 대상으로 하는 경우가 많았다. 그러나, 기술의 발달로 오늘날 대부분의 소스는 Object로 재활용 가능하며, 문서 또한 호환되는 포맷을 ㅗ저장 관리되고 있다.
그러면 마인드는 어떨까?
이 글을 읽으시는 분들은 형상관리가 필요하다고 생각하는가? 귀찮은 추가 작업이니 프로젝트에서 제일 일이 적은 사람에게 할당하거나 마지막 단계에 한꺼번에 수행하자고 생각하지는 않는가? 즉, 프로젝트 관리의 마인드에서 형상관리가 품질보다도 우선순위에서 밀리는 것이 안타까운 현실이다. 애초부터 마인드가 문제지 기술이 문제가 아니었다.
그러나 마냥 여건이 성숙되기를 기다릴 수 없으니 마인드를 바꾸고 여건을 만들고자 이렇게 형상관리 이야기를 시작한다. 여러 회로 연재될 형상관리 시리즈를 통해 많은 분들이 지식을 쌓고, 특히 현업 PM들이 사안의 중요성을 인식하는 계기가 되기를 바란다.
시스템공학자들은 '구성관리'라고도 하고, 소프트웨어 공학자들은 '형상관리'라고 하는데, 호칭은 형상관리가 대중화되어 있다. 영어로는 'Configuration Management'이다.
1. 형상관리란
가. 형상이란
S/W를 개발하는데 있어 하나의 파일만 가지고 모든 실행 모듈이 생성되는 경우는 없다. C언어로 개발되는 경우만 보더라도 그와 관련되는 헤더파일, 라이브러리 파일, 각종 문서들이 있기 마련이다. 이 중에서 우리가 원하는 어떠한 기능을 추가하게 되면 거기에 맞춰서 소프트웨어는 변화를 하게 된다.
예를 들어, A라는 기능을 하게 되는 각 소스들의 버전과 B라는 기능을 하게 되는 소스들의 버전을 달라지게 마련인데, 이때 각 기능을 하기 위한 소스 버전들의 집합을 '형상'이라는 말로 표현하면 이해가 쉬울 것이다. 즉, A라는 기능을 수행하기 위한 각 소스들의 버전의 형태를 '형상'이라고 표현한다.
나. 형상관리 활동의 4가지
- 시스템을 구성하는 각 부품들, 즉 형상관리의 대상으로 삼을 수 있는 것들을 통칭하여 '형상 항목(Configuration Item)'이라 지칭한다. 이들의 기능적/물리적 특성을 파악함으로써 각 형상 항목을 인식하고 구조화하게 되는데, 이를 '형상식별'이라고 한다.
- 각 형상 항목들은 시간에 따라 진화를 하게 되는데 이를 제어하고 기록하는 것이 필요하다. 이를 '형상제어'라 한다.
- 현재의 형상상태 및 형상관리의 진행상태 즉, 현재 각 형상 항목들의 관계나 구현 상태 및 변화 절차를 보고하는 활동이 필요하다. 이를 '형상보고'라 한다.
- 마지막으로 이러한 변경들이 미리 정해진 요구사항과 일치하는가를 점검해야 하는데, 이를 '형상감사'라 한다.
2. 형상관리 도구의 필요성 (형상관리 도구의 기능)
가. 자원의 중앙 집중적 통합관리
형상관리를 하게 되면 가장 먼저 하는 일이 대상 자원들을 구분하고 구조화하는 작업을 하게 된다. 그리고 나서 대상 자원들을 특정한 저장소에 모아두게 된다. 이렇게 하여 자원의 분산 및 중복 보관을 막게 된다.
나. 자원들의 효율적인 버전 및 이력관리
형상관리의 시작이 버전 및 이력관리에서 출발했듯이 가장 기본적인 것이라 할 수 있다. 자원들이 변화가 일어날 때만다 변화에 관련되는 정보, 즉 누가, 언제, 왜, 어떻게 등의 정보를 관리하는 기능이다. 많이 보급되고 있는 문서관리/이력관리 툴들이 형상관리의 일부인 것이다.
다. 작업 공간의 효율적 사용
형상관리 도구들은 고유한 형태의 자원저장소(Repository)를 보유하고 있으며, 사용자 별 또는 작업그룹 별로 리포지토리를 접근하거나 볼 수 있는 권한을 제어할 수 있도록 해 준다. 최근에 떠들썩한 고가의 설계도 유출사건도 이러한 도구를 사용한다면 방지할 수 있는데 안타까운 일이다.
라. 작업의 진행상태 파악 및 효율적 분배
대부분의 형상관리 도구들이 트래킹 기능을 가지고 있어 각 작업 단위 별 작업의 진행상태 및 경과정도 등을 파악할 수 있다. 뿐만 아니라 개발자, 개인 별로 작업의 상태 등을 파악할 수 있어서 관리자들은 작업을 분배하기가 쉬워진다.
마. 다양한 리포트
개발 및 유지보수 동안에 발생하는 다양한 정보들을 기록하고 관리하여 다양한 리포트 형태로 제공한다.
바. 작업 프로세스 지원
형상관리 도구를 통해 각 작업 단계 별로 필요한 작업들을 미리 정의하고, 거기에 준하여 작업할 수 있도록 지원한다는 의미이다.
사. 효율적이고 정형화된 의사소통 수단 제공
현재 나와 있는 형상관리 도구들은 자체적으로 정형화된 형태의 다양한 변경 요청서를 제공한다. 이를 이용하여 사용자들은 자신의 변경 사유를 기술하게 되고, 이것이 형상관리 도구 내에서 각 개인 사용자들에게 할당되게 되는 것이다.
3. 형상관리의 개념과 활용
현재 대부분의 많은 조직들에서 형상관리를 하려고 하고 형상관리 도구의 도입을 적극 검토하고 있다. 하지만 이것은 단순한 필요성에서 기인한 것에 불구하다. 대부분의 조직들이 형상관리 도구를 도입함으로써 자신의 조직들은 완벽한 형상관리를 할 수 있을 것이라 생각을 하기 때문에 형상관리 도구 도입에 실패하게 되는 것이다. 즉, 형상관리를 하기 위해서는 사전에 더 많은 준비를 필요로 하는 것이다.
가. 자유로운 개발을 하는 조직
이와 관련해 개발자들이 중심이 되어 작업을 하는 조직의 형상관리 도구 적용 사례를 살펴본다. 기본적으로 모든 형상관리 환경은 개발자들을 중심으로 구성되기는 하지만 형상관리의 절차를 간과해서는 안된다. 즉, 기본적으로 형상관리를 하는데 있어서의 절차를 무시할 수 없다는 것이다.
개발자 중심의 이 조직은 H/W를 제어하는 S/W를 만드는 조직으로 모든 작업을 개발자들이 담당 업무 별로 하도록 되어 있으며, 조직원들은 각자 업무에 맞는 프로그램을 개발하고 관리하는 일을 자신이 알아서 하도록 규정하고 있다.
이 조직은 한 마디로 모든 개발을 개발자들이 알아서 하는 조직이었다. Unix 환경에서 모든 사용자들이 개발을 하게 되는데 C를 사용하여 개발을 하게 된다. 물론 개발자들은 자신의 워크스테이션을 사용해 서버에 접속하여 개발을 하게 된다. 하지만 이 조직은 S/W를 개발하는 조직이 아니라 H/W에 들어가는 S/W를 개발하는 조직이다. 모든 개발자들은 자신이 담당하는 분야가 따로 있고, S/W를 개발하고 나서는 개발된 S/W는 자신이 담당하는 테스트용 H/W에 옮겨서 테스트를 하게 된다. 이 과정에서 문제가 발생하지 않으면 바로 실제 H/W로 만들어 내게 되는 것이다. 이렇게 작업을 하다 보니 모든 작업자들이 알아서 작업을 하게 되는 것이다.
다만, 개발에 들어가기 전에 변경요청서를 작성하고, 개발과 테스트 과정이 끝난 후 실제 H/W에 적용하기 전에 변경완료보고서를 작성하여 제출을 하도록 규정을 하고 있기는 하지만 실제로 전혀 지켜지고 있지는 않았다. 구두상으로 개발자들이 개발팀장에게 보고하는 형태를 취할 뿐이었다.
나. 적용 전 문제점
가장 큰 문제는 작업의 통제가 안된다는 것이다. 각자가 알아서 개발하고 자신만의 고유한 영역을 확보하고 있고, 모든 관리 역시 개인이 알아서 하는 형태를 취하다 보니 관리가 제대로 되지 않았다. 자신이 만들어 낸 프로그램을 H/W에 이식하여 실행 모듈로 만들어 다른 H/W와 운영에 들어갔을 때 문제가 발생하면 정확한 원인을 파악하는데 많은 시간이 소요가 됐다.
공통되는 모듈의 경우 개인 별로 자신의 작업 영역에 보유하고 있어서 변경이 발생했을 때 다른 사람이 소유하고 있는 것에 반영을 하기 위해서는 많은 시간이 소요가 될 뿐 아니라, 즉시 변경된 내용이 반영될 수 없다는 단점 또한 가지고 있다.
내부적으로 형상관리 절차를 규정하고는 있으나 전혀 지켜지지 않는 상태이고, 전체 개발과정과 관련하여 다른 외부 인증기관으로부터 인증 심사 준비를 하고 있는 상태여서 형상관리와 관련해서도 절차를 명확히 규정하고 조직원들이 이 절차를 정확히 따르는 것 또한 중대한 문제점이었다. 하지만 조직의 특성상 기존 형상관리 도입을 통해 업무 자체가 너무 많은 변화를 일으킨다면 일의 능률이 저하될 수 있으며, 조직원들의 심한 반발을 초래할 소지가 많아서 아주 신중한 적용이 요구되고 있었다.
다.적용 후 운용 환경
일단 가장 중요한 두 가지 작업은 형상관리 절차를 명확히 하는 일이었다. 다음으로는 여기 저기에 보관되고 있는 개발 소스를 한 곳으로 모으는 일이었다.
형상관리 절차는 기존에 사내 규정으로 있던 형상관리 절차를 그대로 이용하는 것을 원칙으로 하였다. 다만 개발자드리 불편을 느끼지 않도록 최소한의 절차로 줄이고 개발자들의 역할 또한 최소한으로 그리고 꼭 필요한 것으로 제한하여 형상관리 도구의 도입으로 인하여 많은 부분에 대해 준비하고 공부해야 하는 시간을 줄이는데 중점을 두었다. 형상관리 절차는 다음과 같다.
개발자들은 개발에 들어가기 전에 변경계획서를 작성하여 개발 팀장에게 승인을 요청하게 된다. 물론 이 과정에서 변경계획서 같은 경우 여러 가지 기본적인 내용 이외에 추가적인 그림 또는 다른 자료들이 있는 경우가 있으므로 파일을 다른 프로그램을 이용하여 만들고, 그 내용을 형상관리 도구로 불러 들여서 사용하도록 정의했다. 이렇게 하면 변경계획서가 개발팀장에게 전달이 되게 되고, 개발팀장이 이 내용을 검토 후 승인을 하게 되면 개발자들이 개발에 들어가게 되는 것이다. 개발자들은 형상관리 도구를 이용해 자신들이 필요한 소스들을 Check Out 하고 변경을 하게 된다.
변경이 끝나게 되면 테스트 과정을 거치게 되고 문제가 없다고 판단되면 변경된 소스를 형상관리 도구로 Check In하게 된다. Check In을 하는 과정에서 개발자들은 변경 완료보고를 작성하여 형상관리 도구에 붙여 넣게 된다. 변경 완료보고서를 작성 후 변경 완료 승인 요청을 개발팀장에게 하게 되고, 이렇게 되면 개발팀장은 전체 사항을 검토 후 승인을 하게 되면 그 내용이 형상관리 담당자에게 전달되게 된다. 형상관리 담당자는 이 단계에서 변경된 소스들을 이용하여 H/W를 만들 수 있도록 개발자들에게 허락해 주는 것이다.
다음 문제는 소스들을 한 곳으로 집중하는 일이었다. 많은 개발자들이 자신의 고유 영역에 개인적으로 소스들을 보관하고 있어 형상관리 도구를 이용하여 관리하기 위헤서는 한곳으로 소스를 모아 놓고 형상관리 도구를 통해서만 모든 소스들에 접근할 수 있도록 하는 일이 아주 중요한 일이었다. 그래서 하나의 서버를 형상관리 서버로 지정하고, 모든 소스들을 이 곳에 모아 리포지토리를 생성했다. 개발자들은 형상관리 클라이언트 모듈을 사용해 서버에 접속하여 작업을 하게 된다.
라. 적용 후 이점
이 조직에서의 형상관리 도입은 처음이나 다름없다. 즉, 미리 준비되어 있는 극본은 있으나 한 번도 무대에 올려지지 않은 연극과 같은 상태였다.
형상관리 적용으로 일단은 기존에 존재하던 형상관리 절차를 강제적으로 적용할 수 있게 된 것읻. 이 절차를 통하지 않고는 개발자들이 개발을 할 수 없도록 막아버림으로 형상관리 절차를 철저히 지키게 됐다. 이로 인해 외부 인증 심사를 아주 좋은 성적으로 통과할 수 있었다. 즉, 형상관리를 통해 기본적인 내부 절차가 정착화 됐다는 것이 가장 좋은 결과라 할 수 있다.
다음은 자원관리 부분이다. 여기 저기 흩어져 있던 자원을 한 곳에 모을 수 있는 기회를 만들었을 뿐 아니라 체계적으로 관리할 수 있는 기반을 마련한 것이다.
개발자들의 고유 작업 영역에는 전혀 변화가 없었다. 다만 개발자들은 변경을 하기 전에 변경을 원하는 파일들을 먼저 형상관리 서버에서 자신의 작업영역으로 Check Out 하는 것 이외에는 특별한 변화는 전혀 없었다. 기존의 작업 디렉토리 구조 및 영역을 유지할 수 있기 때문이다.
형상관리 담당자 입장에서는 전체 개발 주기를 제어할 수 있을 뿐 아니라 형상관리 도구에서 제공하는 다양한 로그를 통해 문제점 발생 시 추적할 수 있는 기반을 구축했다.
다양한 리포트를 통해 작업의 진행 상태를 출력할 수 있게 됐다. 뿐만 아니라 중요한 리포트의 경우는 HTML 문서 형식으로 만들어 기존에 운영하는 인트라넷을 통해 주기적으로 리포팅해 줌으로써 일일이 리포팅을 해야 하는 불편함을 최소화했고, 업무를 좀더 자동화 했다.
마. 도구 선택 시 중요한 원칙
형상관리 도구를 적용하는데 있어서 그리고 형상관리 도구를 선택하는데 있어서 몇 가지 중요한 원칙을 다시 한 번 짚어보도록 하겠다.
먼저 형상관리를 적용하기 위해서는 가장 먼저 환경을 만드는 것이다.
첫째, 형상관리 절차를 만들어야 한다. 여러 차례에 걸쳐 얘기했듯이 형상관리에는 절차도 중요한 요소이다. 단순히 형상관리 도구를 도입해 버전 및 이력관리만을 생각하고 있는 조직이라면 형상관리를 좀더 나중에 도입하라고 말하고 싰다. 비싼 대가를 지불해야만 형상관리 도구를 도입할 수 있는데 이러한 문제는 기본적으로 고려를 해야 할 뿐 아니라 꼭 필요한 요소이다.
또한 모든 표준화 기구 및 인증기관들에서도 단순히 형상관리가 아닌 버전관리만을 하는 것을 지양하고, 일정한 절차에 따라 형상관리를 할 것을 표준으로 제시하고 있다. 또한 단순한 버전관리만을 목적으로 형상관리 도구를 도입하는 경우 대부분의 경우 실패를 하기 마련이다. 이것은 대부분의 개발자들은 형상관리라는 것을 귀찮게 생각하기 마련이고 이렇기 때문에 절차를 만들어 절차에 따라 하지 않으면 개발을 할 수 없도록 만들어야만 개발자들이 형상관리에 적극 참여하도록 해야 한다. 그러므로 형상관리 절차를 만들고 거기에 준하여 작업할 수 있도록 하는 것이 아주 중요한 요소이다.
둘째, 형상관리 환경 구성을 어떻게 할 것인지 설정해 두어야 한다. 절차를 아무리 잘 만들었다 해도 복잡하고 까다롭다면 별 의미가 없다. 또한 형상관리 환경이 절차를 따르지 않고도 개발을 할 수 있는 환경이라면 의미가 없어진다. 그러므로 절차는 간단하고 단순하게 꼭 필요한 부분만을 수용해야 하며, 환경 자체도 절차를 따르지 않고는 변경관리를 할 수 없도록 정의되어 있어야 한다. 예를 들어, 개발 영역과 운영 영역이 동일하다 하면 개발자들은 얼마든지 운영 영역에서 직접 모든 작업을 하는 것을 막을 수는 없을 것이다. 그러므로 일단 운영 영역과 개발 영역을 분리해야 한다. 즉, 개발 영역에서 변경된 내용들이 형상관리 서버를 통하지 않고는 운영 영역에 전달될 수 없도록 해야 하며, 개발자들이 운영 영역에 접근할 수 없도록 해야 한다는 것이다.
셋째, 사용자들의 권한 및 조직원 구성을 어떻게 할지를 설정해야 한다. 사용자들은 어떠한 권한을 가지고 작업을 할 수 있는지 작업할 수 있는 내용과 작업할 수 있는 내용은 무엇인지 미리 정의해야 한다. 이렇게 함으로써 권한이 없는 사람이 실수로 작업해서 발생하는 문제점도 사전에 대비할 수 있으며 또한 각 사용자들 입장에서도 자신에게 불필요한 형상관리 도구의 기능까지 습득할 필요가 없어서 편리성을 갖게 되는 것이다.
바. 도구 선택 시 고려사항
첫째, 일단 우리 환경에 얼마나 적합한지를 살펴보아야 한다. 형상관리라는 것이 단순히 도구의 도입만으로 이뤄지지 않는다. 도구의 도입 시 현재 우리 호나경에 대해 많은 고민을 해야 한다. 그래서 현재 우리가 개발하고 있는 환경에서 최소한의 변화로 적용을 할 수 있어야 하며, 비용 등도 고려해야 할 것이다.
둘째, 많은 기능이 제공되는 툴 보다는 꼭 필요한 기능이 제공되는 도구를 선택해야 한다. 형상관리 도구의 적용에 있어서 많은 기능에 제공된다는 것은 의미가 없다. 집에서 TV를 한 번 생각해 보도록 하자. 많은 기능들이 있지만 채널과 볼륨이외에 얼마나 많은 기능들을 활용하고 있는지에 대해 형상관리 도구도 동일하다. 도구마다 수많은 기능들이 제공된다고 해도 실제 사용자들이 사용하게 되는 기능들은 5%도 되지 않는 경우가 허다하다. 비싼 비용을 들어 많은 기능을 제공하는 도구를 선택하기보다는 우리에게 꼭 필요한 기능을 제공하는 도구를 선택해야 한다. 형상관리 도구들은 대부분 대동 소이한 기능을 제공하고 있는 것이 사실이다. 사용자들 입장에서는 이러한 것을 구분해 내는 것이 그리 쉬운 일은 아닐 것이다. 우리가 꼭 필요로 하는 기능들에 대해 사전에 정리하고 가중치를 두어 도구를 검토할 때 평가 요소로 삼아야 할 것이다.
셋째, 기술 지원 능력 및 사후 관리에 대한 요소들도 점검해야 한다. 마지막으로 기술 지원 및 사후 관리에 대한 요소를 점검해야 한다. 일반적으로 형상관리를 도입 적용하기 위해서는 많은 시간을 필요로 하게 된다. 또한 경험이 전혀없는 조직의 경우는 더 많은 시간과 기술을 필요로 하게 된다. 이 과정에서 형상관리 도구를 지원하는 인력의 기술력과 경험은 아주 중요한 요소가 될 수 밖에 없다. 또한 얼마나 많이 많은 내용을 지원해 줄 것인가도 중요한 평가 요인인다. 현재 국내에는 형상관리와 관련해 많은 기술 지원 인력을 확보하고 있는 상태가 아니다. 따라서 기술 지원을 받기 위해서는 적지 않은 비용이 들게 된다. 형상관리 도구의 도입보다 더 큰 비용이 추가로 지불될 수 있으므로 도입 이후 형상관리 관련 기술 지원에 대한 비용 문제도 확실하게 계획을 세워야 한다.
4. 형상관리 용어
형상관리에서 많이 쓰이는 용어를 나열하였고, 기타사항을 파일로 첨부한다. 용어가 다수 기존의 방법론에서 설명한 것과 중복되는데 그것은 형상관리도 방법론을 지원하는 한 부분이기 때문이다.
가. 설계형상(As-Designed)
제품이 설계된 형상을 말한다. 이의 부품표를 '설계향상 As-Designed) BOM' 혹은 '설계(Engineering) BOM'이라고 한다. 이는 제품 형상의 기초가 되는 것으로 설계자나 고객의 입장에서 만들어진 것이며, 설계변경(Engineering Change)이 여기서부터 시작된다.
나. 생산형상(As-Planned)
설계된 제품을 생산하기 위해 계획한 형상을 말한다. 이의 부품표를 생산형상(As-Planned) BOM 혹은 제조(Manufacturing) BOM이라 하며, 생산 절차를 기술한 문서를 공정설계(Operation Planning)라 한다. 설계형상(As-Planned) BOM이 설계자의 입장에서 만들어진 것인데 비해 생산형상(As-Planned) BOM은 생산기술자에 의해 생산의 용이성이 감안되어 다시 만들어진 것이다. 따라서 생산형상 BOM은 설계형상 BOM과의 차이가 없음이 증명될 수 있어야 하며, 설계변경 사항이 적시에 반영되어야 한다. 특히 생산형상(As-Planned) BOM은 MRP의 가장 중요한 Input이므로 공정설계와 제품구조의 일치성이 보장되어야 한다.
다. 완성형상(As-Built)
완성된 형상을 말하는 것으로 최초 계획에서 설계변경 등 이력을 포함하여 생산 과정에서의 개선사항, 품질검사 결과 및 사후처리, 대체품을 포함한 실제 사용된 부품에 관한 제반사항 등의 광범위한 정보가 포함되어 있다. 이는 사양을 준수하여 제조하였다는 증명임과 동시에 고객에 인도되는 제품의 최종 형상으로 향후 운영 시 유지보수의 기반이 된다.
라. 운영형상(As-Maintained)
고객에 의해 운영되고 있는 형상을 말한다. 항공기, 선박, 첨단장비, 무기류 등은 제품 수명주기가 길거나 안전과 관련된 제품, 프로그램이나 첨단기술이 계속 보강되는 제품들은 현재 상태의 형상이 관리되어야 정확한 부품교환 및 수리가 가능하다. 그러므로 제품과 함께 운영형상(As-Maintained BOM)이 관리되어야 하며, 고객과 정비업체간 상호 운용성을 제공해야 한다.
마. Physical Configuration Audit
형상관리 활동의 하나로서 기능적 형상검토(FCA: Functional Configuration Audit) 이후에 개발 완료된 제품이 생산(또는 출하)에 필요한 요건을 갖추었는지를 검토해야 한다.
5. 형상관리 베이스라인(Baseline)의 개념
시스템의 생명주기의 일정 시점마다 그간의 제품상태(산출물)를 검토하고, 그 결과를 반영하여 다음 개발단계로 이전하는 방법을 사용한다. 이러한 시점이 곧 베이스라인(Baseline)이다.
즉, 베이스라인이란 생명주기 내에서 공학적, 관리적, 획득적 측면을 고려하여 정한 하나의 분기점 혹은 관리점과 그 때의 산출물을 의미하는 것으로써 개발 주기의 각 단계에서 산출되는 산출물에 대해 사용자의 요구조건을 만족시키는지 여부를 공식적인 검증과 확인을 거쳐, 한 단계를 동결하고 다음의 단계를 시작하는 기준점이 된다.
이러한 개발기점(Baseline)은 요구분석, 디자인, 코딩, 테스팅, 변경요청 등을 통제 관리하기 위해 설정하는 것으로 개발활동에 따른 시간의 순차에 의해 설정된다.
일반적으로 개발기점은 다음과 같이 5단계로 구분된다.
- 시스템 기능분류 기점 (FB: Functional Baseline)
- 시스템명세서(SS)의 검토 후 승인되는 시점에서 통제되는 라이브러리로 관리 - 소프트웨어 기능분류 기점 (AB: Allocated Baseline)
- 소프트웨어 요구분석(SRS)의 검토 후 승인되는 시점에서 통제되는 라이브러리로 관리 - 디자인 기점 (DB: Design Baseline)
- 기초(기본)설계 명세서 검토(PDR)와 상세설계 명세서의 검토(CDR) 검토 후 승인되는 시점에서 통제관리 - 최종 산출물 생성 기점 (PB: Product Baseline)
- 프로그램, 통합시험과 시스템 시험규격서/보고서가 검토 후 승인되는 시점에서 통제관리 - 운영개발 기점 (OB: Operational Baseline)
- 최종 산출물인 소프트웨어를 사용자에게 인도하기 위한 인증시험의 종료 후 승인되는 시점을 말하며, 운영의 시작시점인 동시에 유지보수를 위한 기준이 된다. 관리대상인 형상 항목에는 운영자 매뉴얼, 사용자 매뉴얼, 설치 매뉴얼, 목적/실행 코드 등이 있다.
미국방성의 MIL-STD-2167에서는 시스템에 대하여 3단계의 개발기점을 적용하고 있다.
- 기능분류 기점 (FB: Functional Baseline)
- 기능배분 기점 (AB: Allocated Baseline)
- 최종 산출물 생성 기점 (PB: Product Baseline)
이는 주로 제품(산출물) 중심의 단계적개발 접근방법(Phased Development Approach)으로
- 개념정립단계 (Concept Development Phase)
- 체계개발단계 (Development Phase)
- 운용 및 유지보수 단계 (Operation And Maintenance Phase)
로 베이스라인을 중심으로 형상관리 방법론을 적용하고 있다.
예를 들면, 기능배분 기점(AB)에서의 소프트웨어 요구사항 명세서(SRS)와 인터페이스 요구사항 명세서(IRS)를 바탕으로 실제적인 개발이 이루어지는데, 이 과정 중의 시스템 형상을 개발형상(Development Configuration)이라 한다.
이러한 개발 형상을 이루는 문서들을 개발기점(Baseline)의 검토 별로 나열해 보면, 아래 그림과 같다. 그림에서 보는 바와 같이 각 개발단계와 베이스라인은 밀접하게 연관되어 있어 베이스라인을 기준으로 개발단계의 진척을 평가하기도 한다.
예전 군사정보 사이트에서 참조한 자료입니다. 영어로 기술된 베이스라인의 상세 설명입니다. 참조바랍니다.
6. 형상관리 과정
가. 형상 식별
- 형상관리 대상 즉, 형상항목의 기능적/물리적 특성을 파악함으로써 형상항목을 식별하고 구조화
- 관리번호 부여
- 소프트웨어 형상의 구조 변경이 요구될 때 추적이 용이하도록 명확하게 정의
- 통제가 용이하도록 누가, 언제, 무엇을, 왜 정의하였는가 하는 정보를 생성
- 기준선 설정
아래와 같은 문서들이 베이스라인의 설정기준이 될 수 있다. 즉, 아래의 산출물들이 승인되는 시점들을 각각의 베이스라인으로 설정할 수 있다. 베이스라인의 특성에 따라 복수의 산출물들이 한 베이스라인에서 승인될 수 있다.
- System Specification
- Software Project Plan
- Software Requirements Specification
- Preliminary Use Manual
- Design Specification (e.g. Datadesign description, Module design description)
- Source Code Listings
- Test Specification (e.g. Test plan and procedure, Test cases and recorded results)
- Operation and Installation Manuals
- Excutable Program
- Database Description (e.g. Schema and file structure, Intial content)
- As-built User Manual
- Maintenance Documents (e.g. Software problem report, Maintenance requests)
- Standards and Procedures for Software Engineening
나. 형상 통제
- 식별된 형상항목의 변경요구를 검토 및 승인하여 기준선에 변경사항을 반영되도록 통제
- 변경요청자 및 작업수행자가 참여하는 형상통제위원회의 구성
- 형상통제위원회는 기준선 및 변경을 승인하고, 소프트웨어의 형상에 영향을 주는 변경에 ㅐ하여 검토하고 승인
- Access Control, Change Control, Version Control
변경요청 및 처리에 기술되는 문서에는 다음의 항목이 포함되어야 한다.
- 변경사항
- 변경식별번호
- 변경과 관련된 사항
- 변경의 범위와 미치는 영향
- 비용 및 일정에 미치는 영향
- 아래 도시된 문서화 된 변경절차가 존재해야 함
다. 형상 감사
- 기준선에 대한 변경이 미리 정해진 요구사항과 일치하는지 점검
- 기준선의 무결성을 평가하여 공식적으로 승인
- 소프트웨어에 대한 이해도가 높은 그룹(정보시스템 감사, 품질보증조직)에 의하여 수행
- 객관적인 확인 및 검증을 거침으로써 새로운 형상의 무결성을 확보
① 검증(Verification)
- 기준선의 형상항목이 전 단계 기준선으로부터 논리적으로 진화되었는가를 검토
- 사용자 관점에서 요구사항의 이행을 중점적으로 확인
- 소프트웨어 제품을 확인하기 위하여 수행
② 확인(Validation)
- 이전 단계에서 요구한 사항이 현 단계에서 진행했는가 확인
- 기준선 내 형상항목의 논리적인 진행과정을 검토
아래는 감사 시 수행하는 질문의 한 예이다.
- 형상감사위원회가 변경을 검토하였는가? 추가적인 변경사항이 수행되지 않았는가?
- 공식적인 기술검토회를 거쳐서 수정사항을 검토하였는가?
- 공학표준을 준수하여 수행하였는가?
- 변경대상, 날짜, 작성자 및 변경에 대한 상세한 내용이 기술되었는가?
- 정의된 프로세스에 따라 변경, 기록, 보고되었는가?
- 관련된 변경대상이 정확히 수행되었는가?
라. 형상기록
- 소프트웨어 형상 및 변경관리의 식별, 통제 및 감사의 결과를 기록
- 보고서 작성
- 이전 베이스라인의 승인시점
- 현 베이스라인의 시작시점
- 각 형상항목의 요약된 정보
- 변경문서의 상태(거부/승인/대기 등)
- 각 변경문서의 내용
- 변경대상의 상태
- 변경대상의 정보(버전 등)
- 베이스라인 변경에 대한 기술적/관리적인 상태 기록
- 형상감사 기록
7. 형상관리 도입 시 고려해야 할 사항
가. 경영진의 의지
A. 변화에 대한 개발자의 저항을 해소하기 위해서는 경영진의 의지가 확고해야 함
'형상관리를 도입한다'함은 기존 문서처리절차에 추가적인 처리단계가 생기며, 추가작업에 대한 기존 숙련자의 반발은 효과적인 홍보와 대안을 제시하여 저항을 최소화 해야 성공적으로 도입할 수 있다. 예를 들면, 형상관리절차에 따라 문서 등을 배포 전 처리하느데 소요되는 시간과 결정사항이 있는데, 시간이 급하니 생략하거나 시간을 할당하지 않고 기존대로 계획을 세운다면 이것은 작업자의 추가적인 희생만을 강요하게 되므로 형식적으로 수행하는 실패 사례가 된다.
기업조직에서 결정의 최종권한자인 경영진에서 이와 같은 변화를 고려해야 할 형상관리 도입이 성공적으로 정착할 수 있다.
B. 작업자들의 모든 내용을 기록하도록 하고 이를 감시하기 위해서는 경영진의 시간과 비용이 투입 요청됨
최근에 조선소의 설계본이 유출되거나 반도체 설계도가 유출되는 사건이 발생하였고, 기업체에서는 내부자의 보안관리를 철저히 하기 위해 EDMS르 도입한다느니 내부자 보안에 역점을 두는 추세이다. 보안사고는 대부분이 기업 내부자에 의해 발생하게 되며, 사고유형은 대부분이 정보유출과 방치 등이다.
다음 장에 형상관리도구에도 소개하겠지만 형상관리도 도구를 사용하면 효과적인 운영과 작업시간을 절약할 수 있다. 그러나, 이를 도입하게 되면 비용, 교육 및 적응시간에 따른 작업손실 등 시간과 비용이 요구된다. 더구나 일부가 아닌 일부가 아닌 전 부서, 전 프로세스에 적용한다면 경영진은 이에 따른 비용(전문관리부서 신설 등)을 고려해야 한다.
C. 가시성과 추적성의 결핍으로 인한 의사결정의 한계를 극복해야 함
형상관리는 도구를 사용한다고 하더라도 즉각적으로 효과를 측정하기 어렵다. 그 이유는 형상관리는 산출물을 생산하는 도구가 아닌 생산을 지원하는 도구이며, 주 입력물은 산출물과 그에 따른 이력정보이기 때문이다. 이력정보는 산출물이 갱신되면서 생성되므로 산출물이 갱신되어감에 따라 이력정보를 이용하여 추적이 가능하므로 이력정보는 도입 후 즉시 이용 가능한 정보가 아니다.
또한, 이력정보의 입력 시 출처 및 작성자, 날짜 등을 입력하게 되는데 최초 입력 시 충분한 정보를 입력할 수 없는 상태일 수 있다. 이에 대한 공감대를 형성해야 도입 및 활용이 조직에 정착하게 된다. 일례로 제가 수행한 프로젝트에서는 창고에 있는 물건이 언제 제조되었고, 상태가 어떤지도 관리되지 않는 것도 있었다. 물론 관련 문서도 없었으나 관련 담당자도 적절히 할당되어 있지 않았기에 이력이 손실된 것이다.
즉, 이력정보는 산출물의 생성/배포 후 추적과 재활용 시점에 빛을 발하는 것이다.
나. 관리조직의 확립
A. 형상관리를 효율적으로 수행하기 위해서는 품질보증조직과 같은 별도의 조직을 운영함이 바람직함
흔히, 형상관리는 품질조직이 같이 겸임해도 될 것으로 생각하게 된다. 그러나, 이것은 불가능한 궁합이다. 형상관리의 활동 중 형상감사는 형상관리자가 수행하는 활동이 아닌 품질관리 조직이 담당하고 체크하는 것이다. 즉, 품질보증조직이 형상관리를 감시하는 것이기에 같은 조직이 활동을 수행한다면 고양이에게 생선을 주는 형태가 된다.
또한 형상관리는 베이스라인에 따라 운영되며 산출물의 배포/변경을 담당하므로 테스트 및 프로세스의 적적한 수행을 점검하는 품질조직과는 업무성격도 다르다. 분리해서 운영함이 바람직하며, 형상관리 규모에 따라 별도 부서가 담당하는 것도 좋은 방안이다. 보통 프로젝트 레벨에서 별도의 관리자를 부여하기도 하지만 개발자들이 형상관리도구 교육을 잘 받는다면 형상관리는 PM이 할 수 있을 정도로 도구가 잘 되어 있다.
자료의 형태와 량에 따라 다르지만 중앙에서 형상자료를 관리하는 형태인 경우에는 형상 데이터의 정리와 추세를 감시하는 조직이 필요하나 조직 별로 분산하여 관리하는 형태인 경우에는 각 조직의 관리자가 수행하면 충분하다.
B. 사용자와 개발자가 공동으로 형상통제위원회를 구성
형상변경은 베이스라인과 밀접한 관계가 있다. 개발자는 베이스라인 범위 내에서 사전에 정의된 스팩 하에 별도의 의사결정없이 자유롭게 변경할 수 있으나 베이스라인을 초과하거나 스팩을 변경해야 하는 변경인 경우는 사용자와 반드시 합의하여 수행해야 한다. 이를 협의하는 기구를 형상통제위원회(CCB)라고 부르며, 프로젝트에서는 고객측/개발자측이 연합하여 구성하고 기업 내에서는 조직간 대표가 차출되어 구성된다. CCB는 상설조직이 아닌 임시회의기구 성격이므로 필요 시 소직하나 의사결정사항은 반드시 형상관리자가 기록해야 한다.
C. 소프트웨어의 버전 또는 기준선을 승인하고 이엥 대한 변경을 허가해 주는 공식적인 조직이 필수적임
이것은 CCB의 역할이다. 프로젝트의 PM이 임의의 산출물을 납품하고자 하는 것은 개발자의 의지이며, 이를 승인하는 것은 사용자의 의지이다. 따라서, 행위를 CCB에서 처리한다면 1:1에 의한 승인으로 인해 오류를 정정하는 Rework이 매우 줄어들게 된다. 또한, 복수에 의한 결정이므로 안정적인 의사결정을 수행하게 되어 프로젝트 리스크를 완화시키는 효과가 있다. 실제로 CCB는 위험을 완화시키는 역할도 한다.
다. 형상관리도구와 작업절차
A. 소프트웨어 형상항목의 특성 상 정보시스템으로 관리가 가능하므로 자동화 도구가 필요
과거에는 형상항목의 관리대상이 문서인 경우가 많아 단순 폴더 관리하는 툴들이 많았으나 기술이 발전하고 시스템이 복잡해짐에 따라, 관리대상은 일정한 형태가 아닌 Object로 바뀌고, 보안 및 프라이버시보호 등의 기능이 추가되었다.
또한, 다양한 플랫폼을 지원하므로 개발 중에 언제든지 편리하게 저장관리할 수 있어 백업의 효과를 볼 수 있다. 저장된 자료에 대한 효과적인 검색도 지원하여 타 프로젝트 또한 타 부서의 자료를 쉽게 재활용할 수 있는 등 비용절감 효과를 지원한다.
단순관리에서 개발도구와 연동하여 운영되는 도구까지 다양하므로 해당 기업 또는 프로젝트에 맞는 도구를 사용하기 바란다.
B. 도구의 활용에 앞서 소프트웨어 형상관리 작업절차가 확립되어야 함
형상관리 툴은 형상관리의 수단이지 핵심을 아니다. 도구 도입 전에 형상관리대상이 무엇인지 선정하고, 이에 적합한 프로세스를 정립한 후 이에 적합한 도구를 탐색하여 선정해야 되겠다. 대부분의 도구들이 표준프로세스들을 지원하지만 개발도구와 연동성이 약한 도구도 있기에 이 경우에는 개발자의 추가 기록작업이 수행되어야 한다. Visual SourceSafe는 개발도구인 Visual Studio와 연동되는 것이기에 수정 후에는 자동으로 기록되므로 작업자는 기존작업과 다를 바가 없게 되나, Microsoft에서 많이 사용하는 Source Depot의 경우는 별도의 Checkin & out 절차를 수행해야 하는 번거로움이 있다. 그러나 Source Depot의 경우는 세부적인 변경절차에 따른 기록이 가능하고 버그 관리도 수반하는 다양한 목적의 툴이다.
8. 형상관리 도구
가. 형상관리 도구의 특징
형상관리 도구는 복잡한 형상 항목의 인식과 형상관리활동을 지원하는 자동화 도구로서 다음과 같은 역할을 수행해야 한다.
A. 자원의 집중적 통합관리
- 형상관리의 모든 요소는 통합적인 관점에서 통제되어야 한다. 즉, 프로젝트의 사항이 회사 규칙에 반한다면 이를 자동으로 제제해야 하는 것이다. 보안 규정 등을 전사적으로 적용하는 것이 한 예가 될 수 있겠다.
B. 자원의 효율적인 버전 및 이려관리
- 모든 자료의 버전과 수정자, 사유 등 수정 이력은 저장되고 필요 시 추적 가능해야 한다. 이력이 추적되지 않는다면 부당한 수정이나 자료파손에 따른 손실을 감수해야 한다. 즉, 백업도 자동으로 되는 셈이다.
C. 작업 진행상태 파악 및 효율적인 작업 분배
- 각종 자료가 수정검토/승인을 거치고 수행하는지에 대한 상태정보 이력이 추적 가능해야 하며, 수정작업에 따른 서버의 부하가 적절히 분배되어야 한다. 경우에 따라서는 일부 자원이 수정이 집중될 수 있는데, 이에 따른 수정 오류를 방지하기 위해서는 수정상태의 제공 및 오류정정(Resolve) 등이 지원되어야 한다.
D. 다양한 보고서 작성
- 수록자료의 변경이력, 배포이력, 수정횟수, 버전, 차이분석 등 다양한 보고자료가 사용자에게 제공되어야 수정패턴 및 통제규칙 설정에 도움을 줄 수 있으며, 생성자료의 재활용을 위한 검색자료로도 활용된다.
E. 작업 프로세스 지원
- 형상 변경 시 변경요청/검토/승인 등 일련의 세부 프로세스를 도구가 지원한다면 작업자는 매우 편리함을 느낄 것이며, 프로세스의 수행 누락이 없는 생산성 향상에 기여하게 된다.
F. 효율적이고 정형화된 의사소통수단 제공
- 형상이 변경되거나 완료되거나 하였을 경우, 적절한 주변 Stakeholder에게 자동으로 통보하는 수단이 있다면 더욱 편리할 것이다. 또한, 부당한 사용에 대한 경고가 있다면 더욱 보안유지자에 도움이 되겠다. 이력기록에 일정한 양식을 지정하여 사용한다면 사용자간의 의사소통이 간결하게 될 것이다.
G. 통합개발환경과의 연동
- 형상관리의 핵심은 개발시스템을 지원하는 것이며, 재활용 및 버전관리를 통한 생산성향상에 기여하는 것이다. 이때, 개발툴과 밀접하게 연동된다면 수정사항이 이력과 함께 별도의 추가 작업없이 개발시스템에 반영되는 것과 동시에 형상 데이터에도 기록할 수 있다는 것을 의미하는 것이기에 매우 효과적일 것이다. MS의 SourceSafe가 그 예이다.
나. 형상관리도구의 선택
형상관리도구를 선택하는 것은 쉬운 부분이 아니다. 그 이유는 의외로 형상관리에 대한 사용자의 요구가 매우 구체적이기 때문이다. 형상관리에 대해 잘 모르는 사람이라도 평소에 이런 것이 되었으면 좋겠다던가 이것이 낭비다라고 생각하는 것이 있으며, 이것은 본인도 모르게 구체적인 형상관리 도구의 요구사항이 된다. 그만큼 형상관리 도구의 대상은 다양하고 방대한 것이다. 즉, 대형조선소의 설계도에서부터 소프트웨어 요구사항까지 모든 표현자료는 형상관리 대상이 되기에 컴퓨터를 모르는 분들이 생성한 자료도 모두 대상이 되는 것이다.
이러한 사용자의 생각이 잘 조사된 것이 1995년 'Improving Your Process for the Evaluation and Selection of Tools and Environments'라는 보고서에서 10가지 절감규칙으로 소개되었다. Westinghouse에서 선정한 10가지는 다음과 같다.
The Westinghouse common 'Cents' Rules
'Haste Makes Waste (성급은 금물)'
도구를 선정하는 시에는 무엇이 필요하고 요구사항은 무엇인지, 제약사항은 없는지 등을 꼼꼼히 따져 보고 해야 하며, 수많은 기능 중 어떤 기능에 중점을 두고 도구를 선정할 것인지 사전에 계획하는 것이 현명한 접근이다. 형상관리의 전 과정 및 데이터의 다양성 등이 이러한 고려요소가 될 수 있다.
다섯개의 도구가 각각 장점을 가지고 있다고 해서 다섯개의 도구를 모두 선택하지 않을 것이다. 예를 들어, F22개발 프로그램 개발 시 다양한 업체가 다양한 개발환경에서 다양한 프로그래밍언어로 개발되는 시스템을 관리해야 된다. 형상관리팀은 도구 선정 시 통합관리가 되는 것을 우선적으로 고려하였다.
'Practitioners Are Prime Evaluator (경험이 최고)'
형상관리 선정 이것은 경험한 사람이 하는 것이 최적이다. 그 이유는 다양한 툴의 다양한 기능들은 무경험자에게는 선택기준이 아닌 단순한 특징에 불과하기 때문이다.
'Evaluate Against User's Needs (사용자 요구사항에 근거한 평가)'
1989년에 Westinghouse는 SEI의 140개의 평가항목을 요약하여 25개 항목을 만들었으나, 1994년 54개로 늘어나다가 1995년에는 67개로 증가하였다. 이러한 항목의 증가는 형상관리 도구의 발전도 있었지만 사용자 요구사항이 변경되었고, 초보 평가자를 위해 상세한 평가항목을 추가한 것이 원인이기도 한다.
아래표는 형상관리 기능의 간략한 요약과 도구간의 비교표이다. 상세내역은 이후에 설명한다. 아래 형상도구는 이 보고서의 발표당시인 1996년 기준의 도표이다. 요즘 국내에 유행하는 PDM, EDMS 도구 등과 비교해 보시길 바란다. PDM/EDMS도 모두 형상관리 도구의 일종이다.
Taxonomy Five SCM Tools
'Don't Believe It Unless You See It (백문이 불여일견)'
앞서 표에서 제시된 다양한 기능에 많은 사람들이 현혹되기 쉬우나 이에 대한 냉철한 분석이 필요하다. 표에서 표현한 것은 전체 기능 중에 일부인 간단한 기능일 수 있다. 실제 프로젝트에서 사용가능한 시나리오를 생각하고 직접 이를 운용하는 테스트를 하면서 선정하는 것도 현명한 접근이다.
'Don't Buy It Until You've Tried It (사용해보고 구매하자)'
많은 사용자가 단지 자신들의 기준을 만족하였다고 하여 툴을 구매하는 것을 볼 수 있다. 그러나 상당수의 툴들이 기준을 다른 시각으로 해석하여 답을 다는 경우가 많으므로 구매를 최종적으로 결정하기 전에 직접 사용해 볼 것을 권한다. 툴 선정기준은 1차적으로 구매제품의 후보선정기준이며, 직접 테스트 후에는 결정기준이 되는 것이다. 후보를 무조건 최종결정하는 오류를 범하지 말길 바란다.
아래 표는 툴을 선정하는 기준을 수립하는데 도움이 될 기초 질문사항들이다. 예를 들면, 만약 툴이 요구사항을 추적하는 기능이 있어야 한다면, 툴은 반드시 변경관리기능(추적관리 및 추적보고서 기능)이 지원되어야 한다. (CM28이 이에 해당되는데, ADC와 ClearCase가 지원되지 않는군요)
'Pay Now or Pay Later (우왕좌왕하지 말자)'
위의 질문에 단순히 Yes/No로만 단정하지 않는다. 각 질문에 대해 중요도를 할당하고 Yes/No에 대해서도 점수를 할당하여 종합점수로 최종적인 평가를 수행한다. 이러한 평가시간은 오래 걸리지 않게 된다.
'Everything is Negotiable (모든 것을 고려하자)'
제품의 성능/기능에 대해 살펴보았다면, 제품의 구매방법에 대해서도 살펴보자. 일부 공급업체는 1 Copy는 팔지 않는 경우도 있고, 어떤 업체는 할인율을 구매처에 따라 다르게 적용하기도 한다. 모든 요소를 고려하여 구매해야 한다.
'Acquire Only What is Needed (필요분만 구매하라)'
업체의 판매전략과 연관되는 부분인데 업체의 할인공세에 호응하여 개발자 숫자대로 소프트웨어를 구매하였을 경우, "개발자가 동시에 모두 체크인을 하는 경우가 발생할 수 있겠는가?"를 생각해 보아야 한다. 1주일에 2번 일부 PC를 이용하여 체크인하는 경우 구매분량은 매우 적게 결정된다. 따라서, 작업방식의 결정만으르ㅗ 필요분량이 다르게 결정되는 것이다.
'Create a Champlion (툴을 숙지하자)'
툴을 잘 사용하는 사용자는 툴의 특성을 잘 파악하여 최대 효과를 거두기도 하지만 때로는 새로운 요구사항을 툴에 도입하도록 만듭니다. 예를 들면, F22 생산 시, PCMS가 흩어져 있는 사이트에 저장된 자료의 형상관리를 해야 하는 경우가 발생하였고, 이것은 PCMS의 다음 버전에서 지원하게 되었다.
'Be Constructive Not Destructive (개선점을 찾자)'
평가자는 툴이 사용중단될 때까지 지속적으로 툴을 평가하여 기능 중 무엇을 사용하고 있고 무엇을 하지 않고 있는지 파악한다. 이를 통해 문제가 무엇이고 어떻게 해결해야 하는지 알게 된다면 이를 제작자에게 피드백하여 전체적으로 툴의 성능향상에 기여할 수있다. 기존의 상용툴들은 이러한 과정을 거쳐서 개선된 경우가 많다. 제작사의 개선지원여부도 툴 선정의 주요요소가 될 수 있다.
10. 결론
모든 현실이 예측할 수 없게 바뀌듯이 고객의 요구사항은 끊임없이 바뀌고, 분석/설계자는 기술발전으로 시스템의 구조를 바꾸며, 개발자는 코드를 바꾸고 PM은 개발방법론을 변경하게 된다. 모든 변경에는 그에 따른 비용이 발생하며, 이것은 프로젝트의 중요요소가 된다. 따라서 소프트웨어의 변경관리는 프로젝트의 핵심활동 중의 하나이며, 이러한 활동을 지원하는 도구의 사용은 필연적인 것이 되어 가고 있다. 적절한 툴을 선정하여 프로젝트를 성공적으로 수행해야 하겠다.
출처 : http://gmood.tistory.com/tag/형상관리