시소당

유스케이스는 과연 유용한가?

유스케이스에 대한 고객 검토를 하면서 예상대로 대혼란이 일어났다. 개발자(분석가)들에게 유스케이스 개념을 설명하는 것도 쉬운 일이 아니다. 하물며 현업 고객에게 타원 몇 개 덩그러니 그려놓고 업무 범위를 모두 포괄하는 것으로 보이냐고 물으면...

고객은 오히려 비즈니스 프로세스를 그린 그림은 쉽게 생각했다. 메뉴 구조도를 보여줘도 쉽게 애플리케이션 기능 구조를 파악한다. 메뉴 레벨 2단계를 유스케이스로 잡으라는 어처구니 없는 가이드를 비웃은 적이 있다. 유스케이스는 메뉴로 분할할 수 있는 것이 아니다. 기초도 모르는 사람이 전문가랍시고 가이드 한 것일 수도 있지만, 한편으로는 현장 상황을 반영한 어쩔 수 없는 자구책인지도 모른다.


위 그림은 유스케이스 이해가 어려운 이유를 단적으로 보여준다. 현행 업무가 시스템 도입으로 인해 변모하는 모습(TO-BE)를 담고 있어 애초부터 고객들에게 시스템에 대한 이해에 기반한 상상력을 요구한다. 다시 말해서, 지금은 이렇게 일하고 있는데 앞으로는 다르게 일할 것이라고... 프로토타입 화면도 보지 않고 과연 고객이 이를 알 수 있을까?

필 자 스스로도 현재 사이트에서 족보에도 없는 산출물을 만들고 있다. 적어도 국내 SI 현장에선 아직도 개발 과정의 산출물을 넘어서지 못하는 모델이 대부분이다.(그나마도 못하는 경우가 더 많은 것으로 짐작한다.) 고객에게 물었다. 유지보수할 때 모델을 보세요? 고객이 유스케이스 명세를 보나요? 물론 '안본다'가 대답이다. 볼 수 있는 산출물을 만들면서 표준 방법론이라는 틀을 어기지 않으려다보니 족보에 없는 변종을 만들어냈다.

그렇다면 유스케이스가 개발자에게는 유용한가? 비슷한 고민을 하면서 내놓은 해결책을 책으로 발행한 것이 있었다. 거짓말처럼 내가 글을 쓰고 난 후, 10분도 안되서 지인이 알려준 책 서두에 나온 그림을 캡쳐해놓는다.


출처: Use Case Driven Object Modeling with UML: Theory and Practice by Doug Rosenberg and Matt Stephens

출처 : http://younghoe.info/682