WBS(Work Breakdown Structure)와 FBS(Function Breakdown Structure)
이쪽 업계에서 보면 WBS는 무엇인지 대부분이 잘 인식하고 있는데, FBS는 그렇지 않은 듯 하다.
그래서인지 FBS를 정의한다고 하면 WBS와 혼동하거나,
또 간혹은 불필요한 작업이 아니냐는 반응도 심심치 않게 본다.
경험. 혹은 충분한 참조자료가 없는 신규 프로젝트라 한다면,
WBS만이 아닌 FBS도 필수일텐데, 일정에 넣으면 빼라는 말만 들으니 답답하다. ㅜㅜ
일단 간단하게 WBS와 FBS의 차이점을 보자면,
전화를 건다라는 Work를 예를 들면
사람의 행동 > 도구사용 > 의사소통 > 전화기 사용 > 전화 걸기와 같이 Work를 점차로 세분화 할 수 있다.
이런 형식으로 Work를 분류하며 정의하는 것이 WBS다.
이런 형식으로 Work를 분류하며 정의하는 것이 WBS다.
그럼 이와 관련한 FBS는 예를 들면
얼굴 > 눈 > 보기
팔 > 동작
손 > 쥐기
손 > 손가락 > 누르기
와 같이 정의 될 것이며,
일단 위의 두 예에서 WBS와 FBS는 어떤 차이인지 구분이 될 것이다.
사족을 붙이자면 FBS는 AOP의 개념과도 많이 닮아 있는 것이다.
그리고 WBS와 FBS의 활용에 대한 예를 보면 아래와 같다.
전화 걸기 Work를 Function을 가지고 표현하면
눈을 이용해 전화기의 위치를 찾고
팔을 이용해 전화기까지 손을 이동시키고
손으로 전화기를 짚고
손가락으로 전화번호를 누르는 것이 될 것이다.
그리고 이런 과정이 설계 단계에서 반영된다고 하면,
FBS를 통해 프로젝트를 완수하기 위해 필요한 Module 단위의 구분을 할 수 있고,
WBS를 통해 개발 작업의 단위를 구체화 할 수 있다.
또 WBS와 FBS를 종합적으로 감안하면,
개발 계획을 세움에 있어서 개발 우선순위 정리하고, 재사용 대상 기능을 식별 할 수도 있다.
그리고 무엇보다, Coding 작업 이전에 개념적 설계 단계에서 논리적인 검증이 가능하다는 장점이 있다.
논리 검증의 예를 들어보면,
전화 걸기 Work를 수행해야 하는데,
팔이 닫지 않는 곳에 전화기가 있는 경우라면,
다리 > 이동 기능이 더 필요하며, 이 기능을 추가해야 할 것이고,
잡고, 누르는 것이 왼손과 오른손으로 구분되어 행해져야 한다면,
왼손 > 쥐기, 오른손 > 손가락 > 누르기와 같이 분류를 다시 하거나,
좀 더 상세히 할 필요가 있는 것이다.
이런 논리 검증을 통한 후, 상세 설계와 Coding 작업이 들어간다면, 그만큼 시행착오를 줄일 수 있다.
좀 더 상세히 할 필요가 있는 것이다.
이런 논리 검증을 통한 후, 상세 설계와 Coding 작업이 들어간다면, 그만큼 시행착오를 줄일 수 있다.
