지난 시간에 USE CASE를 Activity Diagram으로 전개시키고 이를 다시 세분화하여 추정견적을 냈었다.
그러면서 다음과 같이 규모산정을 하였다.

우리가 산정한 안내를 받는다는 기능은 총 110.9 FP이다.

여기서 잠깐, 위의 챠트는 잠시 잊도록 하자. 먼저 생각해봐야 할 것은 "이 일은 몇명이서 얼마간 일해야 생각했던 기능을 모두 구현할 수 있을까?" 이다.

마치 밥이 한공기 있는데 몇 숟가락 떠먹어야 다 먹을수 있냐?라는 질문과 본질적으로 같은 질문인것 같다.
이를 공식화하면 간단하다

먼저 밥숫갈횟수 = 밥한공기용량/밥숫갈용량, 따라서, 전체 시간은 = 밥숫갈횟수*한숫갈당 씹는시간
물론 소화시간까지 계산한다면 "밥숫갈횟수*한숫갈당씹는시간+소화시간" (이건 잘 기억하자. 다음은 이 단순한 원리로 우리가 알고 있는 상식을 한번 깨보겠다.)

나는 WBS(Work Breakdown Structer)를 협오하는데 그 이유는 바로 Activity와 Due Date, 담당자로만 설정하기 때문이다.
거기다가 2Weeks이상 어떤 Activity 가 길어지면 안된다고 강제하고 있다.
물론 더 쪼게라고 이야기하고 있기는 한데 이거 하나 마음에 든다.
하지만 WBS는 다음과 같은 치명적인 오류가 있다.

첫째, 업무의 규모는 안보인다. 단지 보이는건 업무와 할당된 개발자, 종료일이다. 그게 어렵든, 쉽든 일단 2Weeks이내로 일정을 잡으면 소프트웨어 공학론자 눈에는 합리적으로 일정을 배분한것이 된다.
다시말해 위에서 계산한 "밥한공기의 용량"은 배제되는 것이다. 거기다가 SI 업계는 급하게 모인 개발자의 생산성을 모른다. 따라서, 밥 한숟갈의 용량도 알수가 없다. 즉, 밥한공기의 용량도 모르고 밥한숟갈의 용량도 모르는데 일단 밥먹는 시간은 설정된다.

둘째, WBS는 통제도구이다. "Critical Path"라는게 있다. WBS를 제대로 사용하려면 이 "Critical Path"라는 큰 줄기가 제대로 진척되고 있는지를 살펴야 한다. 그러나, 수 많은 고객을 포함한 감시/감독자들은 WBS의 모든 부분을 가지고 트집잡는다. 논쟁은 논쟁을 낳고 책임은 변명을 낳는 상황이 반복된다. 이말이 사실인지 아닌지를 보려면 WBS를 누가 원하는지를 보거나 기억해 내면 된다. WBS는 고객 또는 PM, 감리가 요청하는 문서이다.

셋째, 몇 개월에 달하는 WBS에 따른 일정 및 업무량을 100% 맞출수 있다면 그 사람에게 1억을 주라. 왜냐하면 그 사람은 로또 번호를 눈감고도 맞출 사람이다. 이말이 와닿지 않다면 이글을 읽는 걸 멈추고 당장 앞으로 10분이후 혹은 1시간 이후 혹은 4시간 이후에 자신이 뭘하고 있을지 상상해보자. 결코 일반 범인들은 10분뒤를 알 수가 없다. 이 포스팅을 시작한게 약 2시간이 흘렀는데 나는 30분 정도 쓰고 말겠다는 생각으로 시작했지만 중간 중간 이벤트가 발생하고 불려다니면서 이미 계획된 일정의 4배를 소모하고도 글을 다 쓰지 못했다. 그런데 몇 개월간의 2Weeks로 쪼게진 업무를 예측하고 계획하라고?

결론적으로 이러한 정형화되고 고정된 형태의 계획은 인간을 못살게 구는 압제의 수단이다.
따라서, 계획은 이렇게 세우는 것이 합리적이다.

1. 가장 먼저 해야할 일은 개발팀의 생산성을 측정해야 한다. 만약 이게 안된다면 연구자료를 참조하자.

물론 다른 자료도 만들 수 있겠지만 개발시 Prototype을 만들어 봄으로써 팀의 평균 생산성을 측정기록할 수도 있다.
여기서 중요한것은 최소한 한숟같의 용량을 측정해야 한다는 주장이다.
((절대 개인이 아닌 개발팀이어야 한다. 개인을 측정하고자하면 그건 또하나의 압제의 수단을 만들 뿐이고 팀웤에 도움이 안된다. 예를 축구 선수는 골로만 평가 받지 않는다. 팀의 기여도 등의 평가 기준이 있는 것이고 아무리 골을 잘 넣어도 혼자 11명을 상대로 할 수 있는건 없다. 개발도 마찬가지다. 고객의 숫자는 항상 개발팀의 숫자보다 많다. 급조한 개발팀이 단시간내에 으쌰으쌰해서 고객을 압도할 수 없기 때문이다.)

2. 정보공학에서 이야기하는 2Weeks는 지켜주자. 왜냐? 근거없는 관습이지만 2Weeks가 넘어가면 관리 한계가 드러나는것 또한 사실이다. (물론 내 경우는 1일이 넘어가면 관리한계가 발생한다.)

3. Critical Path를 먼저 설정하자. 흔히 마일스톤이라는 것으로 표현하면 된다.

암튼 다시 원점으로 돌아가 전체 규모는 110.9이므로 첨부된 파일에 있는 2003년 이후의 개인 생산성인 18FP로 나누자.
그러면 총 6.16 이나온다. 즉, 6.16 M/M가 투입되어야 구현이 가능하다는 이야기이다.
물론 사전 공부가 필요없는 전문가에 대한 이야기이다.
프로토타잎도 만들필요가 없는 전문가에 대한 이야기이다.
암튼 왠지 모르겠지만 어디서나 통용되는 2:8법칙을 적용하여 6.16은 개발 최소기간의 80%로 설정하면 6.16의 25%인 1.23을 버퍼로 추가해서 총 개발기간은 7.29가 되고 학습기간을 고려하면 고정 투자비용 1개월+7.29M/M가 투입되어야 개발이 가능하다. (물론 지도데이터나 음성 데이터등 관련 데이터가 모두 존재한다는 가정이다.)

따라서, 계획은 "Activity Diagram을 보며 업무를 Breakdown할 수있다. + 개발계획은 교육 1개월 + 7.29M/M의 투입이 필요하다."는 간단한 진실로 마일스톤을 그릴수 있는 것이다.
* 다음 그림을 다시한번 상기해보자.

기능 구현업무는 다음과 같이 나열하였었다. (3부에서)

- 초기화는 단순 입력만 이니 EI/ILF
- 목적지이름조회, 목적지주소조회는 EQ/ILF
- 주소목록선택, 목적지목록선택은 EI/ILF
- GPS좌표를 획득하는건 외부 시스템 연동으로 EIF
- 경로획득은 ILF
- 현재좌표획득은 EIF
- 음성안내는 EQ/ILF
- 현재지도갱신 EQ/ILF
- 안내종료는 EQ/ILF

이를 다시 정리하면 다음과 같다.

1. Milestone (예제)
- 개발자교육 (1M)
- Prototype (0.5M)
- 개발구현 (7.29/개발자수)
- 배포 (개발구현완료후)

2. 상세일정
- 개발자 교육 내용 및 추정기간
- Prototype 내용 및 추정기간
- 개발구현 내용 및 추정기간
- 배포 내용 및 추정기간

* 개발구현 상세일정 예제
사용자 삽입 이미지

다시말해 추정기간은 시간이라는 자원을 얼마정도 쓸지 예측한다는 의미이다.
이러게 자원소요계획을 수립하고나면 Milestone을 더 짧게 쪼게서 Iteration을 적용할 수 있다.
예를 들어 개발자 교육이 1개월 걸린다면 짧게 1주일씩 나눠서 4번 반복 할 수 있다.

Iteration1 - GPS시스템이해
Iteration2 - 앞 교육과정 요약 및 네비게이션의 이해
Iteration3 - 앞 교육과정 요약 및 경로추출
Iteration4 - 앞 교육과정 요약 및 음성안내

이처럼 가장 중요하다고 생각하는 내용을 앞에 배치하면 전체 교육기간동안 총 4번의 반복을 통해 피교육자의 이해도를 높일수 있는 장점이 있다. 개발도 마찬가지이다. 가장 중요하다고 생각되고 광범위하게 참조되는 부분부터 Iteration1에 넣어두면 Iteration2를 통해 확장할때 Iteration1에서 개발한 핵심 엔진은 기능확장과 안정화를 거치게 된다. 그리고 또 한번 열게됨으로써 개발자가 코드를 더 친숙하게 여길 수 있는 기회를 준다.

아무튼 이렇게까지 Milestone과 시간사용계획을 짜놓았다면 이제 할 일은 각각의 조직의 역할을 정의하는 일만 남았다.
반드시 CASE by CASE로 짜놓자.
예를 들면 다음과 같이 짜놓는 것이 중요하다.

1. 요구사항 수행절차
 가. 요구사항을 JIRA에 등록한다.
 나. 요구사항은 고객과 개발팀의 협의체에서 우선순위를 조정하여 XX기준(일정 또는 범위 또는 업무량 등등) 으로 상위 OO개를 수행한다.

이렇게 개발공정에서 발생할 수 있는 CASE를 예상하고 각각의 조직과 개인이 해야할 일을 명시해놓고 개발 프로세스에 적용하자. 그래야만 혼란을 미리 막을 수 있으며 Prototype 개발 기간동안 의미있는 데이터를 획득할 수 있다.

암튼, 가장중요한 것은 계획은 계획일 뿐이라는 거다.
계획을 함으로써 앞으로 발생할 일에 대한 자원(인력, 돈, 시간 등)의 소모와 만약(if)에 대한 시나리오를 검토할 수 있는 기회를 준다.

마지막으로 각각의 Iteration에 대한 계획은 나중에 다룰 기회가 있으면 또 한번 다뤄보자.

어쩌다 규모산정을 한 김에 달리다보니 계획까지 와버렸다. -_-;;
어쩐지 진도를 다 못나간 느낌이다. 다음에는 다른 영역으로 진도를 나가보자. -_-;;

2011/03/24 13:37 2011/03/24 13:37

어제에 이어 UML기반의 개발강좌 3편이다.
오늘 할 이야기는 Activity Diagram을 뽑고 Function Point와 연동하여 견적내기이다.
먼저 다음 포스트를 읽고 오자.

[기능점수견적 산정강좌 바로가기]

기능점수 견적을 요점정리하면 다음과 같다.

1. 기능점수는 기능을 가지고 도출할 수 있다.
2. 기능점수는 디자인 등 부가적인 부분에 대해 견적할 수 없다.
3. EI/EQ/EO, ILF/EIF 만 무슨 의민지 알면 기능에 대한 도출은 쉬울 것 같다.

암튼 UML로 이러한 견적을 뽑아 내려면 EI/EQ/EO, ILF/EIF를 도출해야 한다는 결론이 나온다.
그런데 내가 도출한 USE CASE에는 아무것도 보이지 않는다. 그냥 기능만 있지 그 안에 무슨 내용이 어떻게 오고가는지가 없다.
이럴때 쓰라고 있는게 Activity Diagram이다.
즉, Activity Diagram은 Use CASE를 분해해서 표현하는 그림으로 하나의 기능을 세밀하게 쪼게는 역할을 맡고 있다.
물론 내가 사용하는 설계 방식에서는 Activity Diagram은 Class Diagram으로 전개시키는 역할도 맡고 있다. 이건 다음시간에 삺펴보고 암튼 Use CASE 하나를 잡고 쪼게보자.

나는 "경로를 안내받는다"라는 녀석을 선택했다. (왜? 네비게이션은 안내받으려고 사는거 아니었나요?)

1. USE CASE중 "전원을 연결한다"는 "전원을 조작한다"와 중복되므로 삭제했다.

사용자 삽입 이미지

2. 오른쪽 Model Explorer에서 "경로를 안내받는다" Use CASE를 선택하고 마우스 우클릭하여 Diagram을 추가하자.
사용자 삽입 이미지

3. 이름을 USE CASE와 구분하기 위해 "//"를 추가하여 "//경로를 안내받는다"로 변경하였다.
사용자 삽입 이미지
4. 이제 "ToolBox"에 뜨는 Diagram이 다음과 같이 바뀐다. 역시 쓰는 넘만 쓰니까 다 자세히 알필요는 없다.
사용자 삽입 이미지
"ActionState"는 Method가 되는 녀석이다. 어떤 의미인지는 나중에 예제로 표현해 보겠다.
그리고 InitialState, FinalState는 시작과 끝이고 Decision이라는 넘은 분기이다.
나머지는 선이니까 생략.
한가지 주의할 점은 Activity Diagram을 그리는데 Use CASE를 뒤엎을 각오를 해야 한다는 것이다.
이게 무슨 의미인지 "경로를 안내받는다." Activity Diagram을 한번 보도록 하자.
사용자 삽입 이미지
위의 Activity가 과연 사용자 입장에서의 Activity인가? 뭔가 혼자 돌고 있는 그림이라면 Use CASE를 너무 작게 쪼겐것이다.
그렇다면 사용자의 입력을 기다리기 위해 "목적지를 입력한다"라는 녀석과 "경로를 안내받는다"라는 녀석을 합칠 필요가 있다.
따라서, USE CASE를 다시 조정했다.
사용자 삽입 이미지
몇몇 USE CASE를 날려버렸다. 가장 핵심적인 기능부터 접근했기 때문에 가능한 빠른 판단이다.
이제 Swimlane을 사용자 까지 포함시켜서 "경로를 안내받는다"라는 USE CASE를 Activity Diagram으로 전개시킬 준비가 된것이다.
다음은 그 결과이다.
사용자 삽입 이미지

이제 위와 같이 한 이유를 설명하겠다.
첫째, 이렇게 사용자를 포함시킬 수 없다면 그것은 요구사항이 아니다. 따라서, 개별 요구사항을 합쳐서 요구사항을 크게 만들어야 한다.
둘째, 반대로 지나치게 클수 있다. 이경우 인수시험계획을 만들기 어렵다. 지나치게 커서 시험항목이 보이지 않는 것이다. 이경우는 쪼게야 한다.
무엇보다 가장 큰 이유는 위와 같이 요구사항을 Activity Diagram으로 테스트 할 수 있다는 점이다.

아무튼 각각의 ActionState들은  Method와 동일하다고 가정하고 Method에서 사용할 Entity와 부가설명을 달아보자.
사용자 삽입 이미지
이제 내 눈에는 그럴싸하게 보인다.
Method는 총 11개가 도출되었고 Entity도 다수 도출되었다.
물론 네비게이션 전문가가 보기에는 빠진 기능이 많을 것이다. 어차피 빠진건 검토하면서 다시 넣으면 될일이고 현재 생각할 수 있는 기능은 다 들어간 것같다.

업무상 꼬이는 부분도 없으며 요구사항 그자체로는 완벽하다.
아무튼 이제 견적을 한번 때려보자.
- 초기화는 단순 입력만 이니 EI/ILF
- 목적지이름조회, 목적지주소조회는 EQ/ILF
- 주소목록선택, 목적지목록선택은 EI/ILF
- GPS좌표를 획득하는건 외부 시스템 연동으로 EIF
- 경로획득은 ILF
- 현재좌표획득은 EIF
- 음성안내는 EQ/ILF
- 현재지도갱신 EQ/ILF
- 안내종료는 EQ/ILF

이상 대충 뽑았다.
따라서 기능점수 견적은 다음과 같이 작성되어야 한다.
- EI : 8
- EQ : 4
- EO : 0
- ILF : 7
- EIF : 2

하여 결론적으로 간이 견적표는 다음과 같이 나온다. (위에 기능점수 견적산정 링크에서 다운로드 받으세요.)
사용자 삽입 이미지

총 FP점수는 110.9점이 도출된다.
보정계수와 원가산정표로 가서 나머지 보정을 하자.
먼저 기능점수의 복잡도로 "평균복잡도"를 선정했다. 물론 네비게이션 만드는게 쉬운일은 아니겠지만...
사용자 삽입 이미지
규모보정계수는 300점 미만이므로 그대로 두고...
어플리케이션 유형 보정계수는 통신제어용(GPS)이므로 비율을 100% 해줬다. (합계는 100%여야 한다.)
사용자 삽입 이미지
언어는 알아서 하면 되고... 품질/특성 보정계수는 다음과 같이 설정했다.
사용자 삽입 이미지
결과적으로 89,929,418 원의 원가가 발생하고 여기에 이윤 25%를 붙여서 총 112,411,773원의 견적이 완성된다.
물론 여기에 디자인비용, 각종 직접비용은 생략되었으니 이건 알아서 넣자.
사용자 삽입 이미지

이것으로 Activity Diagram으로 USE CASE(요구사항)을 테스트하고 견적을 내는 단계까지 완료.
다음에는 Activity Diagram으로 인수시험CASE를 만들어 보자.

ps. 띰띰해서 그려본 현재 적용한 개발 프로세스
사용자 삽입 이미지

중요한게 바로 요구사항 Pool이다.
요구사항이 들어오면 즉시 실행하는게 아니라 일단 Pool에 넣어둔다.
(왜냐하면 감정을 최대한 없애기 위한 조치이다. 훗날 냉정하게 바라보면 불필요한 기능을 구현하느라 시간을 다 소모했던 경험이 있다면 반드시 적용하자.)
프로젝트 협의체에서는 얼마나 완료되었는지 시연하고, 이슈를 해소하기위해 정책을 정리하고, 요구사항 Pool을 뒤져서 개발우선순위를 조정한다. 우선순위가 조정된 개발범위중 상위 몇개를 골라서 구현지시를 하면 개발팀은 분석설계후, 코딩하고 단위테스트를 진행한다. (Visual Studio는 단위테스트를 자동생성해줘서 권장. 아마도 이클립스도 자동으로 만들어 주는 Plugin이 있을것 같음)
이후에 Build하고 통합테스트라는 테스트를 거친뒤에 개선요구사항과 버그 수정사항을 다시 Pool에다 넣어둔다.
잠깐의 휴식을 가진뒤에 다시 처음부터 우선순위 먹이고... etc etc..

암튼 UML은 이중에서 분석설계서 및 테스트 계획서에 사용됨.
빌드 테스트 결과는 HUDSON을 활용하자.

2011/03/23 14:22 2011/03/23 14:22
TAG ,
일주일쯤 됐나? 암튼 UML 개발강좌 2편이다.
먼저 다음의 그림에 주목하자.
사용자 삽입 이미지
요구사항은 인수테스트로 검토/테스트 되어야 하며, 고수준의 설계는 통합테스트로, 세밀한 스팩정의는 유닛테스트로 검토/테스트되어야 한다.
UML이 아무리 용빼는 재주가 있다고하더라도 이러한 Software Development Life Cycle을 빗겨갈수는 없다.

왜 그럴까?
우선 요구사항이라는 녀석의 존재 때문이다. 요구사항은 어디서 오는가? 너무 당연한 대답이지만 요구사항은 고객에게서 온다.
우선 고객의 특징을 살펴보면,

1. 고객은 단위업무전문가일 경우가 많다. 물론 예외는 존재한다.
2. 고객은 기술적으로는 문외한 일경우가 많다. 아무리 과거에 기술에 몸담았다고 해도 "지금"이라는 시점으로 짜르면 문외한 인건 똑같다.
3. 고객은 자기가 원하는 것을 표현하기 어려워 한다. 특히, 한국은 체면때문에 더 힘들어 한다.
4. 고객은 결국은 돈주는 사람이다.

즉, 고객은 요구사항을 내고 개발이 끝난뒤에 요구사항 대로 개발했는지 검토한후에 그 댓가를 지불하는 사람이다.
그런데, 여기서 문제가 발생한다. 결론부터 말하자면 우리의 좌뇌가 문제이다.
좌뇌는 논리와 언어를 담당하고 우뇌는 감성과 직관을 담당한다.
우리가 누군가에게 말을 하는 이상 좌뇌를 통할 수 밖에 없으며 좌뇌는 다음과 같이 "자동차를 만들어주세요."라고 하지만 우뇌는 어떤 그림을 상상하고 있을 것이다. 아마도 다음의 그림과 같지 않을까?
1. 고객
좌뇌 - 차를 만들어 주세요.
우뇌 -
사용자 삽입 이미지
2. 개발자
좌뇌 - 차를 만들어 달라고 하는구나.
우뇌 -
사용자 삽입 이미지

좌뇌는 똑같은 이야기를 하고 있지만 우뇌는 서로 다른 이야기를 하고 있는것이다.
그러나 우리는 우뇌에서 그린 이미지를 물질세계로 끌어내어 형상화한다.
그래서 우리에게는 말이 아닌 그림이 필요하며 그림을 간략하게 그리기위해 Diagram이라는 도구를 사용하는 것이다.
따라서, UML은 다음과 같이 정의할 수 있다.
"UML은 의사소통의 도구!"
따라서, UML을 자세히 그릴 필요성이 없다는 결론에 도달한다.
자세히 선이 어쩌구요, 뭐가 어떻고 따진다고 한들 그것이 코드로 그대로 반영되는것도 아니지 않는가?
그냥 문자로 되어 있는 요구사항을 Diagram으로 표현한것이 UML의 첫번째 "Use Case"이다.

USE CASE의 정체를 떠들다가 보니 벌써 이렇게 길어지고 말았는데 그 정체를 이렇게 장황하게 설명하는 이유가 바로 정체를 제대로 알아야만 정확한 선이 어쩌고하는 논쟁으로부터 벗어날 수 있으며 어느 정도의 수준으로 Use Case를 나눠야 하는지 기준이 서기 때문이다.
결론부터 이야기하자면

첫째, USE CASE는 요구사항의 집합이다.
둘째, USE CASE는 인수시험으로 검증될 수 있어야 한다.

위의 2개의 기준은 매우 중요한 개념이다. 밑줄 쫙쫙 긋고 머리속에 박아넣고 있어야 하는 개념이다.

이제 우리가 그리기로 했었던 "3D Navigation"의 USE CASE를 그려보도록 하자.

1. StarUML을 실행하고 "Default Approach"를 클릭
사용자 삽입 이미지

2. 이제 USE CASE를 그릴차례 우측 탐색창에서 <<USE CASE MODEL>>을 더블클릭하자
좌측에 도구함에는 Use Case에 사용되는 도구가 뜬다.
사용자 삽입 이미지

우리가 사용할 도구는 UseCase와 Actor, Association, System Boundary 정도이다.
붉은 박스외에 다른 모델들은 나중에 기회가 되면 설명하던가 자습을 하던가... -_-;; 뭐 암튼 그리 중요한건 아니다.
(정말로...)

3. 암튼 제한된 도구로 배치해보니 다음과 같다.
사용자 삽입 이미지
Use CASE 하나 하나는 "인수시험 케이스"라는 생각을 가지고 그리게 되면 위와 같이 된다.
물론 다른 생각을 할 수도 있다. 그러나 나는 이렇게 생각한다. 몇가지 설명을 덧붙이면
사람모양인 Actor는 사용자, 관리자, 외부시스템등을 표현한다. 즉, 현재 네비게이션을 제외한 모든 시스템, 사람을 Actor로 표현하는 것이다.
그리고 화살표와 선이 보이는데 이건 관계를 표현한다. "-->" 하든 "--"하든 둘중 아무거나 상관없이 써도 된다.
단지 나는 사용자의 입력을 표현하는 선은 "-->"로 했을 뿐이다.
그리고 설명이 부족한 부분은 Annotaion을 클릭해서 Note와 Notelink를 사용해 추가적인 설명을 붙여 둔다.
사용자 삽입 이미지
이까지 그리는데 5~10분 정도 걸린것 같다. 자랑이 아니라 대충 그렸다는 이야기다.
왜 대충그렸을까?
이 문서는 끊임없이 살아 있는 생명체와 같기 때문이다. 무슨 이야기냐면 "UML은 개정되어야 하기 때문이다."
매번 개정할텐데 힘들게 그릴 필요가 없다는 의미이다.

아무튼 요구사항이 도출되면 이정도까지 그려두자.
다음에는 기능점수(Function Point) 기준 견적에 관한 이야기를 할 것이다.
2011/03/21 11:19 2011/03/21 11:19
TAG ,

일전에 약속한 UML기반의 개발강좌를 하나씩 열어보고자 한다.

먼저 다음의 USE CASE는 내가 사용하고 있는 개발프레임워크이다. (그중 직접적인 부분만 발췌한것이므로 부가적인 요소는 다음에 기회가 되면 또 한번 이야기해보겠다.)

사용자 삽입 이미지


복잡하지만 프로젝트 관리자입장에서 서술하면 제일 먼저 USE CASE를 그린다.
한가지 주의할 점은 USE CASE는 "고객(사용자)" 입장에서 작성되어야 하며 이렇게 작성된 USE CASE는 3가지 용도로 변형되어 사용된다.

1. 견적서 (기능점수활용)
2. Activity Diagram 등의 분석/설계 문서
3. 사용자 테스트 혹은 인수시험이라도 불러지는 System TEST CASE

즉, 내가 2008년부터 주구장창 사용하고 있는 개발 관리의 근본은 바로 "USE CASE"로 USE CASE의 화살표가 맞고 틀리고는 내게는 커다란 의미가 없다.
이게 중요하다.

다이어그램을 보고 흐름을 알 수 있을 정도로만 작성할 뿐 절대적인 규칙에 맞춰 작성하지 않는 것이 핵심이다.
단지 다른 사람에게 보여주고 다른 사람이 이해할 수 없다고하면 그때 다듬는다.

표현할 수 없는 부분은 Memo를 활용해서 부가적인 설명을 달아 놓으면 그만이다. 이걸 그리는데 담배 한대피고 온 시간까지 총 20여분이 걸렸다.
(왜? 대충 그리기 때문이다. ㅋ)

일단 위와 같이 전개된다는 것만 숙지하고 다음 시간에는 USE CASE를 그리는 방법 (표준이 아니라 내가 사용하는 방법)을 설명하고자 한다.
따라서, 본 강좌는 다음과 같은 순서로 진행할 것이다.

1. USE CASE
2. USE CASE를 활용한 견적서 작성(규모산정 중심)
3. USE CASE를 활용한 System TEST CASE 도출
4. Activity Diagram 전개
5. Class Diagram & Sequence Diagram 도출
6. Unit TEST CASE 도출

이상 6개 항목으로 진행하고자 한다.
그리고 나머지 부분은 따로 시간이 되면 (언젠가는 되겠지...?) 또 한번 썰을 풀어보고자 한다.

그리고 앞으로 사용할 예제 프로젝트를 다음과 같이 선정했다. (강사 맘이다.)

3D Navigation Device 제작

헐퀴.. 그냥 스마트 TV만들기나 뱅킹시스템 사용이나 아니라면 전세계약 시스템 같은걸 선정할걸 그랬나? -_-?
암튼 이것도 강사 맘이다. (배째시라...)
그리고 나아가 어떻게 Agile 프로세스를 적용하면서 Iteration을 나눠야 할지도 그간의 고민을 같이 풀어보겠다.

ps.
행여 본 강좌를 보고 Diagram의 기호 사용법이 틀렸다는 둥 이상하게 그렸졌다는 둥의 이야기는 하지말자.
문서를 만드는데 스토리 텔링이 중요하지 맞춤법, 띄워쓰기 틀렸다고 지적하기 시작하면 아무것도 못한다. 오류가 스토리 텔링에 심하게 영향을 끼치지 않는다면 그것으로 그냥 족한것이다.

ps2.
본 프레임워크는 2008년부터 2011년까지 몇개의 프로젝트를 통해 다듬어진것이다. 더 좋은 방법도 있지만 프로젝트의 문서를 아주 빠르게 만든다는 차원으로 접근해주길 바란다. 그리고 왜 문서를 개발이전에 만드는지도 후에 중간 중간에 썰을 풀겠다.

* 본 강좌는 StarUML을 통해 진행합니다.

2011/03/14 14:01 2011/03/14 14:01

"그래서, 설계는 어떻게 해야하나?"
"UML이면 다된다면서 왜 Doxygen같은 것을 쓰나?"
등등등

최근에 UML을 동료들에게 전파하면서(내것으로 체화된 Agile 개발 방법) 받은 질문이다.
종종 UML에 대한 의문과 질문을 받는데... 특히 Doxygen과 같이 사용하는 부분에 대해 의문을 많이 가지고 있었다.

잠깐 생각을 해보자.

"개발이 과학인가?"

과학이 되려면 몇가지 조건이 있는데 일단 다른 건 다 제쳐두고...
"과학은 누구든 A를 집어넣으면 어디서나 B라는 결과물이 나와야한다."
즉, 객관적이고 타당한 논리는 언제 어디서 누구에게나 대입하더라도 맞아야 한다.
이게 안된다면 과학이 아니다. 그래서 우리는 "XX설"이라는 식으로 정의하거나 "종교"의 이름을 붙이기도 한다.

그런데 개발을 한번 보자.

똑같은 UML이 아니더라도 우리가 익숙한 Workflow diagram을 개발자 10명에게 주고 그대로 개발하라고 하면 같은 결과가 나올까?

오히려 조건중에 시간을 짧게 가지고 갈수록 실패하는 개발자가 더 늘어날 뿐이다.
결론부터 내리자면 개발은 과학이 아니라 "기술(ART)"이다.

다시 주제로 돌아와 UML은 건축설계서와 같은 도면에 불과할 뿐이다.
CASE툴을 가지고 MDA한답시고 상세하게 UML그려서 Code로 Export해봤자. 사람이 100라인으로 끝낼 수 있는 일을 CASE 툴은 그 이상의 쓸데 없는 코드를 양산할 뿐이다.

* 첨부된 논문은 이를 실증한 것이다.



다시말해 UML을 신봉하고 그것이 개발 설계의 전부인양 생각하면 큰 코다친다.
UML은 의사소통의 도구로 활용되어야 하고 살아 있는 지도를 만들기위해 Doxygen과 같은 인공위성 지도를 찍어야 하는 것이다.

다시말해 UML은 "손으로 측량된 지도"라면 Doxygen과 같은 도구는 "인공위성지도"이다.
이 둘을 한번 비교해보자.

먼저 Doxygen만 사용했을때를 인공위성의 지도로 한번 보도록 하자.
사용자 삽입 이미지
어떤가? 알아 볼수나 있을까?
손으로 그린 지도인 UML을 한번 보자.
사용자 삽입 이미지
어떤가? 알아 보기가 훨씬 쉽다.

이제 잠깐 망각의 시간을 보낸뒤 순서를 바꿔보자.
일부로 이미지를 보기 힘들게 더 작게 만들었음을 참고하자.
사용자 삽입 이미지
사용자 삽입 이미지
이미지가 더 작아져서 보기가 더 불편함에도 인공위성사진만 보았을 때 보다 한결 이해가 편하다.

이것이 바로 UML과 Doxygen을 함께 사용하는 이유이다.

앞에서도 증명해보았지만 "개발은 과학이 아니다." 사람마다 훈련받은 강도가 다르고 훈련된 결과가 달라 개발자 한 사람 한 사람이 보유한 기술의 난이도, 성숙도가 다르다.

따라서, 설계과정에서 아키텍트는 모든 역량을 누구나 알아듣기 쉽게 설계서를 그려나가야 한다.
UML이 아니라도 좋다. 일단 나는 UML이 편하기 때문에 사용할 뿐이며 만약 Balsamiq과 같은 Mockup Tool로 그 과정을 밟아가도 괜찮다. 그리고 이해했는지 확인하자.
확인 하는 방법은 간단하다. 스스로 편하다고 생각하는 표기법으로 변환해보라고 하던가. 아니면 WhiteBoard에 그림으로 설명해보라고 하면 된다.

이렇게 확인한 업무를 진행하고 이후에 생성된 Doxygen과 UML을 한번더 검토한후 설계와 다른부분이 나타나면 왜 다르게 했는지 편안하게 물어보고 합리적이라고 생각하면 UML을 고치면 그만이다.

결론은 UML을 맹신하지 말자. 그러나, UML은 커뮤니케이션 도구로 짱이다.


* 추후에 UML 강좌를 한번 Open하겠습니다.

2011/03/09 01:02 2011/03/09 01:02