<그림2-7>은 '채용업무'에 대한 기능 분할의 과정을 보여준다. 먼저 문제공간에서 가장 작은 업무의 단위인 단위프로세스를 도출해낸다. 단위프로세스는 대부분이 실체(Entity; 파일; 테이블; 클래스 등)가 되는 명사형 단어와 그 실체에 어떠한 행위(생성, 수정, 삭제, 조회 등)를 하는 동사형 단어의 형태인 명사+동사의 형태로 작성이 되되, 되도록 상세한 설명이 포함된 명사+동사로 작성한다.
<그림2-7>의 (a)는 초기 기능 분할도이다.
<그림2-7> '채용업무'에 대한 기능분할의 과정
대부분의 프로세스들이 단위프로세스들로 구성이 되어 있다. '채용업무'의 문제공간에서 우선은 업무기능으로부터 단위프로세스로 분석방향을 진행하는 것이 아니라, 단위프로세스로부터 업무기능으로의 하향식이 아닌 상향식의 접근방법을 우선적으로 사용한다.
작성된 단위프로세스가 더 이상 나누어질 수 없는 프로세스인지를 검증할 필요가 있다. 전술한 대로 단위프로세스는 하나의 입력자료와 하나의 출력자료를 가진다. 시스템 분석 초기에는 프로그램을 생각하지 않기 때문에, 단위프로세스와 관련된 입력 자료와 출력자료는 해당 업무와 관련된 자료 예를 들면, 장부, 원장(Ledger), 보고서, 증빙(영수증), 전표 등의 자료들을 생각해 본다.
그림에서 보면 '새로운 이력서 검토'라는 단위프로세스는 검토되지 않은 새로운 이력서가 입력되어 검토된 새로운 이력서의 출력자료가 만들어진다. 출력자료가 하나이상 만들어진다면 하위 단계로 더 나누어질 수 있으므로 그 프로세스는 단위프로세스가 아니라고 생각하면 된다. 이러한 단위프로세스들에서 유사한 종류의 프로세스들끼리 모아서 상위 프로세스를 만든다. 상위 프로세스는 한 레벨이 최대 12개의 프로세스를 넘지 않는 선에서 6-7 레벨로 나뉘어질 정도로 계층화가 이루어지면 가장 바람직한 분할이 이루어졌다고 볼 수 있다.
유념할 것은 시스템 분석가는 현업 실무자에게서의 업무 분석결과 이외에는 추측이나 상상에 의하여 업무프로세스를 추가하거나 함부로 누락시키지 말아야 한다는 것이다. 기능 분할도에 나타난 모든 단위프로세스는 거의 모두가 실제의 프로그램 모듈이 된다는 것을 생각한다면, 현업 실무자의 요청이 없었는데도 업무프로세스를 추가한다는 것은 정해진 프로젝트 기한을 지키지 못하는 일이 발생될 수도 있고 심지어는 현업 사용자가 활용할 수도 없고 운영할 수도 없는 프로그램을 제작하게 되는 우를 범할 지도 모르고, 업무 프로세스를 누락시키는 것은 더더욱 시스템을 완전하게 구축하지 못하는 일이 될지도 모른다. 원칙대로 기능 분할도를 작성하는 지침에 충실하여 작업을 수행하면 가장 만족스러운 시스템 분석작업이 이루어 질 수 있다는 것이다.
<그림2-7>의 (b)는 중간 과정의 기능 분할도를 나타내고 있다. 이때 아주 중요한 분할 지침은 프로세스의 이름을 균형 있게 명명하는 일이다. 어떤 노련한 분석가는 국어사전을 옆에다 놓고, 현업실무자까지 참여시켜 프로세스 이름을 지정한다고 하니 프로세스 명명이 기능분할도의 작성 나아가서는 시스템 분석의 성공적인 임무 수행에 얼마나 중요한 것인지를 짐작할 수 있겠다. 중간 기능 분할도처럼 단위프로세스를 식별하는 일부터 상향식으로 구조화된 기능 분할도는 어느 정도 유사한 업무프로세스들끼리 모아지면 반대의 하향식 접근방법으로 다시 말하면, 업무기능영역에서 업무기능으로, 다시 업무기능에서 업무프로세스로 계층화를 시킨다. 상향식과 하향식 접근식의 계층화를 반복적으로 하다 보면 만족스런 기능 분할이 이루어지게 된다.
<그림2-7>의 (c)는 완성된 최종 기능 분할도이다.
<그림2-7-c> 최종 기능 분할도 |