USE CASE의 중요성

난 UML을 그릴 때 visio 나 visual studio 2015 enterprise 버전을 이용한다. Xcode에는 없는 기능이다.

https://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview-KOR/Visual-Studio-Ultimate-2012-Improving-architecture-through-modeling-KOR

이런 동영상이 있긴 하지만 사실 UML은 많이 보고 또 많이 그려보는 수 밖에 답이 없다. 그리고 USE CASE의 모든 규칙을 지킬 필요도 없다. 소통을 위한 것인데 규칙이 많을수록 서로 소통이 어려워지기 때문이다.

USECASE는 requirements analysis 단계에서 작성하는 것이고 그것은 고객과의 의사 소통을 돕기 위해 만드는 것이지 내가 아는 지식을 자랑하려고 하는 것은 아니기 때문이다. 그리고 대부분의 고객은 돈이 많은 정도와 알고 있는 IT 지식이 반비례 하는 경우가 많다. 내가 하청을 받을 때는 몰랐는데 직접 고객을 만나 대응하는 경우 우 수백억의 자산가들은 IT에 대해서 전혀 모른다. 

보통은 use case를 그리지도 않고 구두로 설명하거나 해당 기술을 설명할 때 기껏 써봐야 sequence diagram, 개발자를 데리고 나온 경우 class diagram 정도였다. 그 중에서 나이 드신 분들도 좋아하는 것은 졸라맨(Actor)이 있는 use case 이다. 졸라맨과 벤다이어그램 하나면 시스템 전체를 설명할 수 있으니 정말 좋다.

그리고 같은 시스템이라도 다양한 관점에서 표현하고 구두로 설명하다보면 고객은 이해를 하고 IT 문외한인 자신도 이해하는 쉽고 자세한 설명을 할 수 있는 사람을 고수로 본다. 돈이 많은 데에는 이유가 있고, 대부분의 IT 기업 사장들이 그러하듯, 돈만 많고 IT는 전혀 몰라... 하는 식으로 접근하면 제대로 된 일을 따기란 불가능 하다고 생각하면 된다. 예전엔 먹혔지만 요즈음엔 다들 영악해서 일을 따더라도 헐값에 처리하거나 갑자기 다른 업체로 넘어가기도 한다.

쉽게 표현해 보자.

 

이런 경우 use case는 requirements 단계에서 작성하는 것이 아니게 된다.

어려운 용어는 SDS 단계에서 고려하는 것이 맞다. 그리고 졸라맨(Actor)이 "어라? 저게 뭐지 하면 안된다.

다시 그리면 다음과 같다. Visual Studio 2015 Enterprise 버전에서 그렸다.

 

액터에 이름을 따로 붙이지 않더라도 그냥 사람으로 생각이 될 것이고(그림부터가 사람)

사람 1과 2가 상호 작용을 할 수 있는데 사람 1, 2는 대부분 같은 기능을 공유한다.

사람1의 경우 메세지를 공유할 수 있지만 사람2는 메세지를 공유 할 수 없다는 것도 알 수 있다.

똑같은 기능이라도 여러번 그릴 수 있다. 목적은 내가 잘 그리느냐 못 그리느냐는 것이 아니라 사용자의 IT 지식 수준을 맞추고 이해시키는 것이 주된 목적이다.

그래서 요구사항 정의 단계에서 가장 먼저 선행되는 것은 용어의 정의, 용어의 명확화, 커뮤니케이션 할 때 빈번하게 나올 법한 

최소 개체에 대한 학습과 same page에 있기 위한 훈련이다.

사실 개발 전단계의 워크샵이 이런 것을 논의하기 위해 가는 것인데 뭐, ... 대부분 술먹고 놀자하고 끝나버려서,

개발은 온전히 나의 몫 ㅠㅠ

 

이제 나이가 드니 기본적인 다이어그램은 그리고 소통하는 개발자와 일하고 싶다.