영향분석 vs. 형상관리 시스템에 대해서.
IT/ALM / 2008. 6. 23. 17:43
오늘은 타 시스템 인터페이스에 대한 회의를 오전, 오후로 2건이나 진행하고 사무실에 돌아왔더니 집중이 않되고 있습니다.
진행하고 있던 SDSM2008 Specification을 계속 작성할까? 하다가. 떡본김에 제사 지낸다고 영향분석과 형상관리의 연동에 대해서 이야기 해 볼까 합니다.
주) 영향분석이 Impact Analysis인지, Visualization인지, Insight인지는 정의하지 않겠습니다. 여러 벤더에서 조금씩 다른 Concept으로 정의하고 비지니스를 하고 있기 때문에 조금씩 다릅니다. 통칭해서, (한국형으로) 소스중에 "이것" 바꾸면 어떻게 되는지 알려 줄 수 있는 시스템을 지칭하겠습니다.
관심의 초점이 되는 것은 두가지 관점에서 이야기 할 수 있습니다.
1) 영향분석 할려면, (최종)소스를 받아가야 하는데, 어떻게 해야 하나요?
2) 변경요청서등(관련 양식)에서 영향분석 결과를 보고 싶은데 어떻게 해야 하나요?
형상(혹은 버전)관리는 ALM영역에서 중심적인 레파지토리 역활을 거의 필수 적으로 담당하고 있기 때문에, 영향분석 뿐만 아니라 다양한 전문화된 도구툴(요구사항관리, 빌드관리, 배포관리, 일정(공수)관리, 테스트관리,,,,관리들)과의 연동이 필요 합니다.
Eclipse 제단에서 ALF(Application Lifecycle Framework) 형태를 Framework을 제안하기도 했으니 연동 + 인터페이스가 가장 큰 화두 인것은 틀림이 없습니다.
위에서 이야기 한 두가지 관점중 처음 소스를 가지고 가는 방법은 의외로 쉽게 해결이 됩니다. 많은 버전관리도구들이 레파지토리에 대한 직접적인 접근은 허락하지 않지만, Command Line 및 API를 통해서 최종 버전에 대한 접근은 허락하고 있는 편입니다.
물론 실물파일과 논리적인 분석 트리에 대한 맵핑.(실물파일 폴더구조가 반드시 영향분석 폴더(?)구조와 일치하는 것은 아닙니다.)
레파지토리 접속에 대한 인증과 Get(Download)한 실물 파일에 대한 보안(책임).
Get시점과 주체에 대한 정의.
신규 + 변경 + 삭제 목록 정보에 대한 처리.등 협의를 통해서 대부분 해결이 가능합니다.
실루엣에서도 기본적으로 SCC(Silhouette Client Command Console)을 통해서 Get, CheckOut을 제공하고 있으며, 변경정보 목록에 대해서는 SDEC(Silhouette Data Export Console)을 통해서 SAM File형태로 제공 합니다.
하지만, 변경요청서등 화면에서 영향분석 결과를 보여준다든지, 변경처리 프로세스에서 영향분석 프로세스를 강제화 한다던지 하는 커플링 인터페이스 작업은 경우에 따라서 많은 커스터마이징을 필요로 하게 됩니다.
일반적으로 국산이든, 외산이든 이러한 경우에 대한 API가 준비되어 있지 않은 경우가 많고, Workflow의 특성상 고객의 Need에 따라서, 변경을 해야 하는 경우가 많기 때문입니다.
단순히 결과를 보여주는 정도라면, 상대방의 시스템을 Unique한 ID로 Call하는 정도의 노력으로 구현 할 수 있지만, 상태정보를 상호 주고 받으며 통제해야 하는 경우에는 새롭게 개발하는 경우가 대부분입니다.
그나마, 요즘은 웹서비스를 통해서 많은 시스템들이 비교적 쉽게 인터페이스 하고 있기때문에 얼마나 다행인지 모르겠습니다. 미팅을 하면서도, 웹서비스를 제공하시나요? 그러면 WSDL열어드릴테니, 호출하시면 되겠네요...라는 대화가 자연스럽게 됩니다.
영향분석과 형상관리의 연동은 그 어떤 시스템이라도 동일하겠지만, 사용자의 요구와 의지치가 가장 중요한 결정요인입니다. 타 시스템과의 인터페이스 커플링을 높여야 한다면, 반드시 그 당위성과 수반하는 비용을 감수 할 정도의 "니드"가 정립되어야 하기 때문에, 혹시 그러한 연동을 고려 하신다면, 조직에서 필요한 정도를 우선 정의하라고 권해 드리고 싶습니다.
진행하고 있던 SDSM2008 Specification을 계속 작성할까? 하다가. 떡본김에 제사 지낸다고 영향분석과 형상관리의 연동에 대해서 이야기 해 볼까 합니다.
주) 영향분석이 Impact Analysis인지, Visualization인지, Insight인지는 정의하지 않겠습니다. 여러 벤더에서 조금씩 다른 Concept으로 정의하고 비지니스를 하고 있기 때문에 조금씩 다릅니다. 통칭해서, (한국형으로) 소스중에 "이것" 바꾸면 어떻게 되는지 알려 줄 수 있는 시스템을 지칭하겠습니다.
관심의 초점이 되는 것은 두가지 관점에서 이야기 할 수 있습니다.
1) 영향분석 할려면, (최종)소스를 받아가야 하는데, 어떻게 해야 하나요?
2) 변경요청서등(관련 양식)에서 영향분석 결과를 보고 싶은데 어떻게 해야 하나요?
형상(혹은 버전)관리는 ALM영역에서 중심적인 레파지토리 역활을 거의 필수 적으로 담당하고 있기 때문에, 영향분석 뿐만 아니라 다양한 전문화된 도구툴(요구사항관리, 빌드관리, 배포관리, 일정(공수)관리, 테스트관리,,,,관리들)과의 연동이 필요 합니다.
Eclipse 제단에서 ALF(Application Lifecycle Framework) 형태를 Framework을 제안하기도 했으니 연동 + 인터페이스가 가장 큰 화두 인것은 틀림이 없습니다.
위에서 이야기 한 두가지 관점중 처음 소스를 가지고 가는 방법은 의외로 쉽게 해결이 됩니다. 많은 버전관리도구들이 레파지토리에 대한 직접적인 접근은 허락하지 않지만, Command Line 및 API를 통해서 최종 버전에 대한 접근은 허락하고 있는 편입니다.
물론 실물파일과 논리적인 분석 트리에 대한 맵핑.(실물파일 폴더구조가 반드시 영향분석 폴더(?)구조와 일치하는 것은 아닙니다.)
레파지토리 접속에 대한 인증과 Get(Download)한 실물 파일에 대한 보안(책임).
Get시점과 주체에 대한 정의.
신규 + 변경 + 삭제 목록 정보에 대한 처리.등 협의를 통해서 대부분 해결이 가능합니다.
실루엣에서도 기본적으로 SCC(Silhouette Client Command Console)을 통해서 Get, CheckOut을 제공하고 있으며, 변경정보 목록에 대해서는 SDEC(Silhouette Data Export Console)을 통해서 SAM File형태로 제공 합니다.
하지만, 변경요청서등 화면에서 영향분석 결과를 보여준다든지, 변경처리 프로세스에서 영향분석 프로세스를 강제화 한다던지 하는 커플링 인터페이스 작업은 경우에 따라서 많은 커스터마이징을 필요로 하게 됩니다.
일반적으로 국산이든, 외산이든 이러한 경우에 대한 API가 준비되어 있지 않은 경우가 많고, Workflow의 특성상 고객의 Need에 따라서, 변경을 해야 하는 경우가 많기 때문입니다.
단순히 결과를 보여주는 정도라면, 상대방의 시스템을 Unique한 ID로 Call하는 정도의 노력으로 구현 할 수 있지만, 상태정보를 상호 주고 받으며 통제해야 하는 경우에는 새롭게 개발하는 경우가 대부분입니다.
그나마, 요즘은 웹서비스를 통해서 많은 시스템들이 비교적 쉽게 인터페이스 하고 있기때문에 얼마나 다행인지 모르겠습니다. 미팅을 하면서도, 웹서비스를 제공하시나요? 그러면 WSDL열어드릴테니, 호출하시면 되겠네요...라는 대화가 자연스럽게 됩니다.
영향분석과 형상관리의 연동은 그 어떤 시스템이라도 동일하겠지만, 사용자의 요구와 의지치가 가장 중요한 결정요인입니다. 타 시스템과의 인터페이스 커플링을 높여야 한다면, 반드시 그 당위성과 수반하는 비용을 감수 할 정도의 "니드"가 정립되어야 하기 때문에, 혹시 그러한 연동을 고려 하신다면, 조직에서 필요한 정도를 우선 정의하라고 권해 드리고 싶습니다.
