필자의 경우 분석과 설계를 4단계로 분리하여 계층화하여 진행합니다.  오늘은 그 첫 번째 단계인 업무분석 래밸을 다뤄보도록 하겠습니다.  다른 활동은 무시하고 동적분석(Job Flow)에만 집중해서 설명하도록 하겠습니다.  저는 다른 활동은 생략하더라도 동적분석만큼은 생략하지 않고 있습니다.


동적분석을 생략해서 안되는 이유

만약 개발자에게 전달되는 스팩(지시사항)이 정확하다면, 복잡한 분석 및 설계 활동은 필요가 없습니다.  하지만, 현실에서 그런 일이 얼마나 될까요?  결국 개발자는 불완전한 스팩으로 개발을 진행할 수 밖에 없습니다.  그러다 보면, 개발 과정 중에 부실한 스팩 때문에 새로 추가되는 요구 사항들을 처리해야 하거나 변경 요소를 적용해야하는 경우가 비일비재합니다.  이에 대한 적절한 대응을 하기 위해서 매번 시시콜콜한 변경 사항마다 분석가 또는 설계자가 다시 개입해야 한다면 프로젝트는 정체를 거듭하게 될 것 입니다.

개발에 참여된 모든 구성원들이 전체의 줄거리를 공유하는 것은 아무리 반복해도 지나치지 않을 정도로 중요한 이슈입니다.


동적분석의 방해 요소 - 고객

업무분석 단계에서 개발팀은 고객에게 의지할 수 밖에 없습니다.  하지만, 동적분석 만큼은 고객이 상당한 방해요소가 됩니다.  업무를 잘 알거라고 생각하는 고객이 실제로는 업무 전체의 흐름을 제대로 파악하지 못한 경우가 많습니다.  

아주 오래 전에, 조금은 큰 기업의 프로젝트를 맡아서 업무분석을 진행하고 있을 때 였습니다.  몇 시간 동안 개발 담당자들에게 각 부서의 업무를 듣고 있는데, 담당자들의 말이 서로 다르고 스스로도 헛갈려 하는 탓에 미팅이 점점 길어지고 있었습니다.  이에, 제가 칠판에 Job Flow를 그리면서 "당신들의 업무는 원래 이래야 하는데, 이렇게 된 것이 아니냐?  여기가 중복되어 혼선이 가고 있는데 한 부서로 책임을 이관하라.." 등 정리를 해 준 적이 있습니다.  이를 목격한 후배가 가끔 술 자리에서 꺼내는 일화입니다.

그러면, 왜 몇 년을 그 일을 해 온 담당자보다 몇 시간 설명을 들었던 제가 업무를 더 자세히 파악 할 수가 있었을까요?  그것은 개별 업무에 너무 집중하지 않고, 각 부서간의 의존 관계를 머리 속에 그릴 수 있었기 때문입니다.  즉, Job Flow를 통해서 각 객체들 간의 메시지 흐름을 그리는 훈련을 반복해 온 탓에 교통정리가 쉬워진 것 입니다.  담당자들은 자신의 업무에 너무 익숙해져 있고, 타성에 젖어 있었기 때문에 그 일이 다른 부서에게 어떤 영향을 주고 어떻게 처리되는 지 전혀 관심이 없었던 것 입니다.  큰 기업일 수록 이런 문제는 더욱 심각해집니다.

그리고, 꼭 동적분석이 아니더라도 고객은 상당한 방해 요소입니다.  자신들이 필요하는 것을 잘 알지도 못하며, 성실하게 생각하려고 하지 않습니다.  그래서, "고객의 요구사항은 언제나 미완성" 이라는 것을 명심해야 합니다.

따라서, 고객이 원하는 것에 머물지 않고, 고객이 필요한 것을 연구해야 고객이 방해 요소가 아닌 동반자가 될 수 있습니다.  그리고, 다시 한 번 강조하지만, 고객은 자신이 필요한 것을 알지 못합니다.  여러분들이 이를 끌어 내야 합니다.


기능분석으로 기초 자료 생성

고객에게 업무 전체의 줄거리를 명확하게 전달 받을 수 없기 때문에, 여러분들은 플로우를 요구하는 대신 상대적으로 쉬운 기능 목록을 받는 것에 집중해야 합니다.  동적분석을 위해서는 기능분석이 기초가 됩니다.

기능분석은 고객의 각 담당자와 우리가 개발해야하는 시스템이 외부로부터 받아야 할 메시지와, 자신이 외부로 전달해야 할 메시지의 목록을 만드는 과정입니다.  이중에서도 외부로부터 받아야 할 메시지는 해당 객체의 기능이되며 핵심이 됩니다.  그리고, 외부로 전달해야 할 메시지는 이벤트로 처리됩니다.

시스템 이외의 담당자들 그리고 시스템과 의존성을 가진 시스템의 외부 엔티티들의 기능분석을 진행해야 하는데, 처음부터 전체의 윤곽을 조사하는 것은 어렵기도 하고 효율적이지 않기 때문에 쉽게 알 수 있는 부분들만 진행해도 됩니다.

우리가 개발하려는 시스템은 최대한 하나의 객체로 생각하면서 Job Flow를 그려갑니다.  그러나, 설명이 명확해 진다면, 굳이 이 원칙은 지키지 않아도 됩니다.

[그림 1] 기능 트리


[그림 1]은 우리가 개발하려는 시스템을 하나의 객체로 보고 각 담당자들 또는 외부 엔티티에 대한 기능 목록을 작성한 것 입니다.  쇼핑몰 시스템을 예로 들었으며, 실제 개발 과정 전체를 설명 할 것이 아니기 때문에 간략하게 정리된 상태입니다.  실제 개발 과정에서도 너무 세밀하게 조사 할 필요는 없습니다.  [그림 1]은 한 눈에 봐도 엉성해 보입니다.

기능 트리는 추후 개발 일정을 예측하는 근거 자료로 사용됩니다.  이 부분은 다른 강좌를 통해서 정리하도록 하겠습니다.


이벤트는 생략되었지만, 이벤트도 함께 조사하는 것이 좋습니다.   예를 들어서 시스템이 재고가 부족할 때 관리자에게 이를 통보해야 할 의무가 있다면, "재고부족"이라는 이벤트가 추가되어야 합니다.  이는 외부 객체에게 전달되어야하는 메시지 목록이기 때문입니다.


가장 중요한 이벤트부터  개별 시나리오를 완성해 나간다.

이벤트를 시작으로 시나리오를 만들어 가야 하는데, [그림 1]에서 조사된 것은 기능 중심으로 조사되었기 때문에 이벤트 목록이 부족합니다.  이러한 때에는 가장 중요한 기능을 하나 선택해서 그려 나갑니다.  어자피 한 번에 끝나지 않을 것이기 때문에 잘못 선정된 것들은 추후 수정 할 기회가 생깁니다.

일단 시스템의 결제처리를 기능으로 보고 시나리오를 작성해 나가도록 하겠습니다.

[그림 2] 시스템의 결제에 대한 시나리오

[그림 2]처럼 시스템의 결제에 대한 시나리오를 작성하려다 보니, 결제 기능을 처리하기 위해서 이를 호출하는 외부 객체가 누락되었음을 발견하고 사용자 객체(엔티티)를 추가하였습니다.  사용자는 구매하고자하는 물품을 선택하고, 배송지 등의 정보를 입력한 이후 "결재 승인 요청" 이벤트를 발생하여, 해당 메시지를 시스템에게 전달합니다.  실제로는 웹 브로우져를 통해서 전달되는 것을 가정으로 합니다.  시스템은 이를 처리하고 난 이후 에러일 경우와 정상 처리일 경우의 메시지를 반환 합니다.  에러의 경우 대응에 관한 메시지 등을 화면에 출력하면 좋을 것 입니다.  하지만, 우리는 아직 화면 설계 단계가 아니기 때문에 이러한 내용은 뒤로 미룹니다.

만족스러운가요?  아닙니다!  우리는 무엇인가 변화될 요소가 있는 지?  빠진 내용은 없는 지 살펴야 합니다.  결제는 대개의 경우 자체적인 시스템이 아닌 외부 대행사를 통해서 처리합니다.  이를 PG라고 표기하고 다시 Job Flow를 작성해 보겠습니다.

[그림 3]
 
[그림 3]은 PG를 추가하여 다시 그린 Job Flow 입니다.  크게 설명 할 것은 없어 보입니다.  그런데, 그려 놓고 보니 사용자는 돈만 내고 물건은 누가 보내 주는 건가요?  아차!!  또 다시 Job Flow를 수정합니다.

[그림 4]


[그림 4]는 택배 회사를 추가 엔티티로 등록하여 다시 그렸습니다.  PG사에서 승인이 떨어지면, 택배회사에게 주문번호 및 베송지 등의 정보와 함께 "배송의뢰" 메시지를 보냅니다.  여기서도 문제가 발생하면 사용자에게 에러 내용과 함께 에러 메시지를 반환합니다.  제대로 처리되었을 경우에는 송장 번호 등을 포함한 메시지를 돌려 받게 되며, 이는 추후 배송 추적 등에 사용됩니다.

좀 더 고민하고 회의를 진행하다 보면 무궁 무진한 요소들이 추가될 것 입니다.  그러는 동안 [그림 1]에서 누락되었던 기능들도 추가되어 점차 완전한 형태의 기능목록이 완성되어 집니다.  이는 이미 밝혔던 것처럼 개발 일정을 예측하는 중요한 자료가 됩니다.  Job Flow는 하나의 시나리오가 완성되면, 다음 중요한 기능이나 이벤트를 시작으로 다른 시나리오를 만들어 갑니다.  이후 서로 다른 시나리오를 합쳐야 하거나, 하나의 시나리오를 여러 개의 시나리오로 나눠서 설명하는 것이 더 효율적일 경우가 발생합니다.  그러한 과정을 여러 번 거치다보면 전체 업무의 줄거리가 완성되게 됩니다.

Job Flow는 줄거리를 그려나가면서 누락된 요구사항을 찾아내는데 상당한 도움이 됩니다.



어느 대기업 프로젝트에 대한 일화

이름만 대면 바로 알만한 대기업의 프로젝트를 맡아서 진행했었던 일화입니다.  해당 기업 어떤 이사님의 지시로 각 담당자들이 2 주 동안 죽어라고 만들어낸 요구사항을 받아 들었지만, 전혀 만족스럽지가 않았습니다.  가장 심각한 문제는, 너무나 낙관적인 고객의 개발 일정 예측이 터무니 없이 짧았다는 것입니다.

"줄거리가 없어!"

결국 투입되는 첫 날부터 2 주 동안 모든 담당자들을 인터뷰하면서 요구사항 명세서를 다시 작성하였습니다.  상당한 눈총을 받으면서...  자신들이 만든 요구사항이 완벽하다는 의미였습니다.  그러나, 쏟아지는 Job Flow..

어느 정도 시간이 흐르자 담당자들이 스스로 Job Flow를 그려오기 시작하고, 회의 중에서도 제가 그린 것을 수정하면서 열띤 토론을 벌였습니다.

Job Flow는 플로우 차트와 닮았고, 이는 학생들이 배울 정도로 이해하기가 쉽습니다.  조금만 익숙해지면 업무분석 래밸 정도는 일반인들도 쉽게 그려 나갑니다.


결국 2 주 정도의 시간이 흐르고 완성된 요구사항 명세서를 보더니 모두들 놀라기도 하고 만족스러워 하더군요.  그러나, 개발 일정은 원래대로 진행되었습니다 ㅠ.ㅠ  (당연하자나요!)

'소프트웨어 공학' 카테고리의 다른 글

상속과 위임에 대한 가벼운 예제  (0) 2013.04.29
인터페이스 릴레이  (0) 2012.06.01
Job Flow - 1단계 업무분석 래밸  (3) 2011.12.19
Jow Flow 작성의 기초  (0) 2011.12.14
Job Flow의 소개  (1) 2011.12.14
데이터베이스 설계의 기본 원리  (0) 2011.02.12

Posted by 류종택


티스토리 툴바