RadarURL
Skip to content
조회 수 873 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

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

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

기능점수 견적을 요점정리하면 다음과 같다.
01.jpg
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중 "전원을 연결한다"는 "전원을 조작한다"와 중복되므로 삭제했다.

02.jpg

2. 오른쪽 Model Explorer에서 "경로를 안내받는다" Use CASE를 선택하고 마우스 우클릭하여 Diagram을 추가하자.
03.jpg

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

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

아무튼 각각의 ActionState들은 Method와 동일하다고 가정하고 Method에서 사용할 Entity와 부가설명을 달아보자.
09.jpg
이제 내 눈에는 그럴싸하게 보인다.
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

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

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

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

ps. 띰띰해서 그려본 현재 적용한 개발 프로세스
15.jpg

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

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

 

출처 : http://wolfpack.pe.kr/i/entry/601

TAG •
?

PageViews   Today : 694   Yesterday : 1,534   Total : 19,194,297  /  Counter Status   Today : 184   Yesterday : 507   Total : 1,252,533
Site Info   Member : 58  /  Total documents : 1,197   New documents : 0  /  Total comments : 25

Edited by JAESOO

sketchbook5, 스케치북5

sketchbook5, 스케치북5

나눔글꼴 설치 안내


이 PC에는 나눔글꼴이 설치되어 있지 않습니다.

이 사이트를 나눔글꼴로 보기 위해서는
나눔글꼴을 설치해야 합니다.

설치 취소