정보시스템 감리의 실제적인 업무 내용

정보시스템에 있어서 감리 영역은 시스템이 잘 구축되어 있는지 점검하는 것이다. 그 기준은 설계 문서가 될 것이다. 설계 대로 구축이 되어 있는지 측면이 구현이 잘되었다고 할 수 있다. 설계도 확인을 해야 한다. 요구사항 대비 요구사항이 반영이 잘되었는지를 봐야 한다. 요구사항이 설계에 반영이 되고, 실제 구현이 잘되었는지까지 봐야 한다. 그리고 구현체가 문제는 없는지를 봐야 한다. 결국 다리를 건축했다고 하면 감리는 이 다리가 원래 설계 목적에 맞게 잘 만들어졌는지 봐야 한다. 안전점검을 하듯이 감리를 하는 것은 시스템이 잘 운영될 수 있게 만들어졌는지 체크를 해보는 것이다.

이론적으로는 그러하고, 현실적인 대부분의 시스템 감리는 일주일 정도의 시간을 가지고 한다. 주로 산출물 리뷰 및 인터뷰로 진행이 된다. 감리사들은 프로젝트 현장으로 가서 요구사항, 설계 산출물, 실제 구현된 형상 및 테스트 결과등으로 정합성을 보게 된다.

프로젝트 구축 기간에 비해서는 짧은 시간에 전체가 잘되었는지를 본다는 것은 쉽지 않다. 그래서 감리를 한다는 것은 상당한 내공이 필요하다. 감리를 할 수 있는 자격이 있어야 하고, 상당한 현장 경험을 필요로 한다. 인터뷰를 하면서 문제가 될만한 부분을 찾아낼 수 있어야 하고, 어떤 산출물을 보고 무슨 문제가 있을 수 있는지를 통찰력있게 진단을 해야 한다. 시시콜콜한 문제로 시비를 걸자는 취지는 아닐 것이다. 

구축을 하고 실제 결과가 적법한지 그리고 운영을 할 수 있는 수준인지등을 볼 것이다. 감리 결과로 시정에 대한 내용도 적절해야 한다. 프로젝트를 전체적으로 다시 구축해야 할 수준은 아니여야 할 것이다. 물론 문제가 있다면 그렇게 해야겠지만, 더 나은 방법이나 안을 찾아주는 것이 좋을 것이다. 현실은 그러하지 못하겠지만, 그래서 프로젝트 매니저들은 현장에 있는 상황에 대해서 감리인들에게 협조적으로 자료 및 산출물 그리고 인터뷰에 응해야 할 것이다. 건설 처럼 감리사가 책임을 져야 하는 책임 감리를 아니다. 하지만 감리의 역할만큼은 확실히 하여 그 역할이 부각될 수 있게는 해야 할 것이다. 감리를 한다고 해서 무턱대고, 문서 처음부터 들여다 보는 것이 아니다. 감리도 나름의 프레임워크가 있다. 그 프레임웍에 맞춰서 전체적인 흐름이 맞는지를 보는 것이다.

이 프레임워크는 점검에 대한 기준이 될 수 있다. 감리인단은 감리 보고서를 제출해야 한다. 이 근간이 되는 것도 감리 프레임워크이다. 구성요소에는 사업 유형/감리시점, 감리영역, 감리기준/점검기준으로 나뉜다. 계획대비 사업이 잘 수행되었는지, 개발의 라이프사이클에 맞게 점검한다. 일관성이 있는지, 성과는 달성이 되었는지를 보게 된다. 감리가 형식적인 행위가 아니라 감리 항목들에 대해서 집중하고 점검하여 상호 시너지가 날 수 있는 기능을 해야 할 것이다.

책처럼 전체를 보기를 원하시면 아래 링크를 클릭하시고 북마크 하셔서 보시면 편리합니다. 

https://wikidocs.net/22352