Cá kỹ thuật đánh giá ông sứ và nguồn lự trong quản lý dự án phần mềm sử dụng hướng tiếp ận điểm hứ năng sử dụng ucp

L a ựchọn phương pháp điểm chức năng ử ụng Use Case Point để đánh giá công sứs d c d ựán phần mềm, thực hiện các thử nghiệm đối với một dự án phần mềm đã có, thửnghiệm và đánh giá thực t

B Ộ GIÁO DỤC VÀ ĐÀO TẠ O TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

Chu Xuân Bảo

CÁC KỸ THUẬT ĐÁNH GIÁ CÔNG SỨC VÀ NGUỒN LỰC TRONG QUẢN LÝ DỰ ÁN PHẦN MỀM SỬ DỤNG HƯỚNG

TIẾP CẬN ĐIỂM CHỨC NĂNG SỬ DỤNG UCP

Hà Nội – 2013

Tai ngay!!! Ban co the xoa dong chu nay!!! 17061131809121000000

Chương 2 PHƯƠNG PHÁP ĐÁNH GIÁ CÔNG SỨ : C PH N M M S Ầ Ề Ử

D ỤNG HƯỚ NG TI P C Ế ẬN ĐIỂ M CH ỨC NĂNG SỬ Ụ D NG 35

Chương 3 : XÂY D NG CÔNG C H TR Ự Ụ Ỗ Ợ XÁC ĐỊ NH GIÁ TR PH N Ị Ầ

M Ề M BẰNG PHƯƠNG PHÁP USE CASE 73

Chương 4 : TH NGHI M ÁP D NG TRONG D ÁN XÂY D NG PHÒNG Ử Ệ Ụ Ự Ự

MÔ PH ỎNG ĐIỀ U KHI N TÀU BI N Ể Ể 86

3

4

DANH MỤC CÁC BẢNG

B ng 1- 1 Tính UFPs – kích c x lý thông tin thô – trong FPA 19ả ỡ ử

B ng 1- ả 2 Mườ ối b n Yế ố kĩ thuậu t t trong FPA 20

B ng 1- 3 Phân lo i ch phát tri n sả ạ ế độ ể ản phẩm trong COCOMO cơ sở 24

B ng 1- 4 Các Yả ếu tố điề u ch nh trong COCOMO trung c p 26ỉ ấ B ng 1- 5 Phân lo i ch phát tri n trong COCOMO trung c p 27ả ạ ế độ ể ấ B ng 2- 1 S p xả ắ ếp chức năng phần mềm 59

B ng 2- 2 Phân loả ại và đánh trọng s m Use Case trong UCP 61ố điể B ng 2- 3 Ví d m s ả ụ đế ố Use Case sau khi đánh trọng s 62ố B ng 2- 4 Phân loả ại và đánh trọng s tác nhân trong UCP 63ố B ng 2- 5 Ví d m s ả ụ đế ố tác nhân sau khi đánh trọng s 64ố B ng 2- ả 6 Trọng s c a 13 y u t ố ủ ế ố kĩ thuật trong UCP 66

B ng 2- 7 Ví d ả ụtính Yế ố Độ ức tạp Kĩ thuậu t ph t trong UCP 67

B ng 2- ả 8 Trọng s c a 8 y u t ố ủ ế ố môi trường trong UCP 68

B ng 2- 9 Ví d ả ụtính Yế ố Độ ức tạp Môi trườu t ph ng trong UCP 69

B ng 2- 10 Tả ổng hợp đánh giá giá trị ầ ph n m m 72ề B ng 3- ả 1 Kịch b n Use Case “Th c hiả ự ện ước lượng m i” 75ớ B ng 3- ả 2 Kịch b n Use Case“Tìm kiả ếm đánh giá lịch s 75ử” B ng 4- 1 S p xả ắ ếp chức năng phần mềm 93

B ng 4- ả 2 Bảng chuy n t ể ừchức năng sang Use Case 98

B ng 4- ả 3 Tính toán điểm các tác nhân trao đổi thông tin với phần m m 99ề B ng 4- ả 4 Tính toán điểm các trưởng hợ ử ụp s d ng 100

B ng 4- 5 Tính toán h s phả ệ ố ức tạ ỹp k thu t công ngh 101ậ ệ

B ng 4- 6 Tính toán h s ả ệ ố tác động môi trường và nhóm làm vi c 102ệ

B ng 4- ả 7 Tổng h p tính toán t ng giá tr ph n m m 103ợ ổ ị ầ ề

5

DANH MỤC HÌNH VẼ

Hình 1 1 Đồ ị ộ ụ đánh giá Độ th h i t chính xác của đánh giá công sức phần m m ch ề ỉ được c i ti n chính trong quá trình phát tri n 10 ả ế ể

Hình 1-2 Tiến trình cơ sở đánh giá công sức phần m m cề ủa dự án 17

Hình 2 1 Một ví dụ biểu đồ Use case 38

Hình 2 2- biểu tượng tác nhân trong UML 41

Hình 2 3– Các Use case trong hệ thống điều khiển máy tàu 46

Hình 3 1 Bi ểu đồ Use Case t ng th - UCPEstimation 74ổ ể Hình 3 2 Bi ểu đồ ạt độ ho ng c a Use Case"Th c hiủ ự ện đánh giá mới dự án" 76

Hình 3 3 Bi ểu đồ ạt độ ho ng c a Use Case"Tìm kiủ ếm đánh giá lịch s " 76ử Hình 3 4 Biểu đồ ộ c ng tác cho Use Case"Thực hi n dánh giá m 77ệ ới" Hình 3 5 Biểu đồ ộ c ng tác cho Use Case"Tìm kiếm đánh giá lịch s " 78ử Hình 3 6 Bi ểu đồ ần tự tu cho Use Case"Thực hiện đánh giá mới" 79

Hình 3 7 Biểu đồ ầ tu n tự cho Use Case"Tìm kiếm đánh giá lịch sử" 80 Hình 3 8 Biểu đồ ự th c th - liên k t 82ể ế Hình 3 9 Bi ểu đồ ự th c th -m i quan h - UPC Estimator 83ể ố ệ Hình 4 1 Hình v ph i c nh cabin chính t h p mô ph ng 86ẽ ố ả ổ ợ ỏ

6

DANH SÁCH CÁC TỪ VIẾT TẮT

ER : Effort Rating ỉ ệ ỗ ự – t l n l c

u ch nh điề ỉ

chỉnh

7

MỞ ĐẦU

1 Cơ sở khoa học và thực tiễn của đề tài:

Công s c ph n mứ ầ ềm liên quan đến c thả ời gian và nguồ ựn l c ph i b ra trong ả ỏquá trình phát tri n ph n m m Viể ầ ề ệc dự báo, đánh giá công sức ph n m m là mầ ề ột

hoạt động mang tính quyết định đối với sự kh ả thi của dự án phần mềm, chỉ ra phương án điều khi n th i gian và ngân qu trong su t quy trình phát tri n ph n ể ờ ỹ ố ể ầ

m m ề

nh ỏ không mang tính đại di n dệ ẫn đến kết quả không chính xác

ph n m m ầ ề

2 Mục đích của đề tài :

phân tích các đặc đ ểi m của các phương pháp định giá s n phả ẩm phần mềm L a ự

ph n m m Hầ ề ở ọc Viện Hải Quân

3 Các vấn đề cần giải quyết của đề tài:

3.1 Nghiên cứu cơ sở lý thuy t và n n công ngh cơ b n ph c v nhi m v ế ề ệ ả ụ ụ ệ ụ

đề tài

8

Nghiên cứu các cơ sở lý thuyết và các công nghệ có liên quan đến việc dự báo, đánh

mềm Nghiên cứu, so sánh, phân tích đánh giá các mô hình truyền thống, các mô

3.3 Học tập các mô hình thông d ng, thụ ử nghiệm, hi u ch nh các thông sệ ỉ ố

và th ng kê kố ết quả ự th c hiện tiến trình trên mô hình, k t lu n v tính khế ậ ề ả thi, độ

3.4 Áp d ng, thụ ử nghiệm đánh giá tại m t sộ ố phần m m và d án tri n khai ề ự ể

t i Trung tâm huạ ấn luyện Mô ph ng – H c vi n H i quâ ỏ ọ ệ ả n

4 Nội dung luận văn:

V i các phân tích và yêu c u nêu trên, luớ ầ ận văn bao gồm các phần sau:

M u ở đầ

điều khi n tàu bi n ể ể

K t lu n ế ậ

Trong quá trình th c hi n Lu n v n, do th i gian ự ệ ậ ă ờ cũng n ưh trình còn hđộ ạn

ch nê hông thế n k ể tránh kh i nh ng thi u sót R t mong nh n ỏ ữ ế ấ ậ được s góp ự ý của

các th y, cô giáo và ầ các bạn để Lu n v n hoàn thi n h n Tô in chân thành cậ ă ệ ơ i x ảm

ơn s hướự ng d n, giúp t n tình c a thẫ đỡ ậ ủ ầy hướng dẫ PGS.TS Hun, ỳ nh Quyế t Thắng, các ầth y trong viện công nghệ thông tin và truyền thông Đại học Bách – khoa Hà Nội giúp i trong quá trình h c t p c ng nh trong quá trình làm đã đỡ tô ọ ậ ũ ư

Lu n v n ậ ă

9

CHƯƠNG 1 TỔNG QUAN CÔNG TÁC ĐÁNH GIÁ CÔNG SỨC

TRONG QUẢN LÝ DỰ ÁN PHẦN MỀM

1.1 Đánh giá công sức phần mềm là gì

Trong quản lý dự án phần mềm, việc đánh giá công sức phần mềm hiệu quả

là m t hoộ ạ ột đ ng quan trọng, đồng thời cũng là một thách th c trong phát tri n phứ ể ần mềm Đánh giá công sức phần mềm là một trong những nền tảng cho việc lập lịch

tin cậy Khi đó, cùng với vi c ph i chệ ả ịu các tác động tài chính, bị ấ m ợ ế ạt l i th c nh tranh, và ch m tr trong viậ ễ ệc hưởng l i tợ ừ ế k hoạch và các sáng ki n là h u quế ậ ả ủ c a

khoa h ọc

nh

án Hình 1 , tham kh o t tài li u ([6] McConnell, 1996) th-1 ả ừ ệ ể hiện độ ộ h i tụ ủ c a đánh giá công sức ph n m m ầ ề trong vòng đời phát tri n d án c a các d án th c t , ể ự ủ ự ự ế

trong vòng đời phát tri n c a d án là r t khó Chúng ta ph i ch u nhi u thi t h i ể ủ ự ấ ả ị ề ệ ạhơn như là một h u qu , do ó, chúng ta c n t p trung nhi u n l c đ gi i quy t ậ ả đ ầ ậ ề ỗ ự ể ả ếtình hình

10

(c) t o ra m t l ch trình làm vi c quá ng n (dạ ộ ị ệ ắ ẫn đến s m t uy tín do th i h n ự ấ ờ ạ

th a thuỏ ận với khách hàng không được tôn tr ng) ọ

ng

cách thêm nhi u y u tề ế ố ừ th a vào đánh giá, thì việc đánh giá ừ th a công sức của m t ộ

Xác đị nh

s n ph ả ẩ m đượ c đ ồ ng ý

Đặ ả c t thi ế t kế chi tiết

S n ph ả ẩ m hoàn thành

Đặ ả c t thi t k ế ế

s n ph m ả ẩ

Đặ ả c t yêu c u ầ

0.6

0.8 0.85 x 0.9 1.0 x

Hình 1 1 th h Đồ ị ộ i tụ đánh giá Độ chính xác của đánh giá công sức phần mề m

(b) m t nhi u thấ ề ời gian hơn để hoàn thành (dẫn đến đánh mất các cơ hội), và

(c) trì hoãn việc sử dụng tài nguyên ở các d ựán tiếp theo.

1.2 Các bước cơ bản trong đánh giá công sức phần mềm

c

yêu cầu một kết quả đánh giá kích cỡ ủ c a phần mềm được phát tri n theo sể ố dòng

dùng những đơn vị ít chính quy hơn (số đặc tính, s yêu c u tố ầ hay đổi, số trường hợp

s ẽ được đề ậ ở c p phần sau

mô hình tính toán liên hệ ỗ ự n l c vớ ỡ ủi c c a ph n mầ ềm và năng suấ ủt c a đội phát tri n ể

tính toán từ ỗ ực được đánh giá và là mộ n l t hàm số ủ c a kích cỡ đội phát triển Điều quan tr ng là ph i nh n th c rõ rọ ả ậ ứ ằng đây không phải là m t quan hộ ệ tuyến tính và ở

nguyên cho vi c phát tri n ệ ể

12

công (ví d , giá kh u hao cụ ấ ủa các phầ ứn c ng và ph n m m c n thiầ ề ầ ết được cung cấp cho d án) ự

1.2.1 Đánh giá kích cỡ của phần mềm

M t ộ đánh giá chính xác v kích c c a ph n mề ỡ ủ ầ ềm được xây dựng là bước

đầu tiên cho m t k t qu ộ ế ả đánh giá có hi u qu Các tài nguyên thông tin v ph m vi ệ ả ề ạ

trường h p, chúng ta ph i xem xét các m c đ r i ro và không ch c ch n trong m t ợ ả ứ ộ ủ ắ ắ ộđánh giá cho m i khía c nh và ph i th c hi n l i viọ ạ ả ự ệ ạ ệc đánh giá công sức ph n m m ầ ề

hi n ệ đánh giá ạ l i m t d án ộ ự ởnhững pha sau của vòng đời dự án, các tài li u thi t k ệ ế ế

có th ể được sử ụng để d cung c p thêm thông tin chi ti t ấ ế

án tương tự trong quá kh và bi t thông tin kích c s n phứ ế ỡ ả ẩm đã được phát tri n, ể

phần trăm của kích cỡ ủa phần tương tự ủa dự án trướ Đánh giá kích cỡ ổng thể c c c t

của dự án mới bằng cách c ng l i các kích c ộ ạ ỡ được đánh giá ủa mỗi phầ c n

Ho c là, chia sặ ản phẩm thành nh ng ph n cữ ầ ấu thành (các đặc tính, các trường

những phép đếm thô như là mộ phép đánh giá ựt tr c tiếp của kích cỡ ần mề ph m,

biết, theo một phép tính trung bình, bao nhiêu LOC hoặc FP mà mỗi phần này yêu

c u trong nh ng d ầ ữ ự án trước

án m i là g n gi ng v i d ớ ầ ố ớ ự án trước

s d liở ữ ệu, các báo cáo, các thông điệp, …

1.2.2 Đánh giá nỗ lực

Một khi chúng ta có ết quả đánh giá ề kích cỡ ủa sản phẩm, chúng ta có k v c

phần mềm xác định và tiến trình phát triển mà ta sử ụ ổn định trên dự án để d ng phân tích, thi t k , phát tri n và ki m th phế ế ể ể ử ần mềm

mềm đơn thuần trên thực tế, việc mã hóa chỉ– chiếm chưa đến 1/2 tổng thể ỗ ực n l

có th phân ph i, và thể ố ẩm định, ki m thể ử mã chiếm ph n lầ ớn hơn của nỗ ự l c dự án

tổng thể Đánh giá ỗ ực dự án yêu cầ n l u ta xác định và ính toán, sau đó tổng hợp t

đánh giá

1 Cách thứ ấ dùng dữ ệ ị nh t: li u l ch s ử - là dùng dữ ệu lịch sử ủa chính tổ li cchức đ xác để ịnh bao nhiêu n l c theo kích c ỗ ự ỡ đã được đánh giá mà các dự án

Dĩ nhiên, cách thức này gi nh r ng : ả đị ằ

(a) T ổ chức của chúng ta đã lập tài liệu các kết quả ực tế ừ các dự án th t trước;

14

(b) Chúng ta có ít nhất mộ ựt d án trong quá kh v i kích c ứ ớ ỡ tương tự (rõ ràng

là tốt hơn nếu chúng ta có nhi u d án v i kích cề ự ớ ỡ tương tự để ủ c ng cố ằ r ng chúng

ta cầ ổn địn nh m t mộ ức độ nào đó của nỗ ự ể l c đ phát triển các dự án c a kích củ ỡđược đưa ra;

(c) Chúng ta sẽ tuân theo một vòng đời phát triển tương tự, sử ụng mộ d t phương pháp phát triển tương tự, các công c ụ tương tự, và có một đội phát tri n v i ể ớ

rất khỏ Chúng ta có thể ử ụng một cách ếp cận thuật toán đã hoàn thiện và đã c, s d ti

nghiên cứu một số lượ ng lớn các dự án đã hoàn thành từ nhiều tổ chức khác nhau đểxem xét các kích cỡ ự d án ánh xạ như thếnào v i nớ ỗ ự l c dự án t ng c ng Các mô ổ ộhình “dữ ệ li u công nghi p” này có thệ ể không được chuẩn xác như là dữ ệ li u lịch sử

n lỗ ực gần đúng hữu ích

Vấ n đ đánh giá ỗ ự ề n l c tr c ti p ự ế

c

n lỗ ực được đánh giá trực tiếp từ ột mô tả ủa sản phẩ m c m/d ự án, bỏ qua hoàn toàn

sinh vấn đề Các đánh giá ự tr c ti p t i nế ớ ỗ ực đã ngầ l m giả định năng suất của đội phát tri n cể ụ ể Khi đó nế th u, giống như thường th y là, ấ các đánh giá ban đầu không theo các mục đích của chúng ta, vi c làm l i ệ ạ các đánh giá để xem điề u gì x y ra v i ả ớnhững đội phát triển khác đòi hỏi việc đánh giá ải đượ ph c tính l i t u B ng cách ạ ừ đầ ằđánh giá kích c ỡ trước chúng ta d dàng làm l i nhanh ễ ạ các đánh giá ỗ ự n l c cho

những năng suất làm vi c khác nhau c a nhệ ủ ững đội phát tri n khác nhau ể

15

1.2.3 Đánh giá lịch trình

a m

xác định l ch trình d án t ị ự ừ các đánh giá ỗ ực Điề n l u này thường đòi hỏi vi c tính ệtoán s ố lượng người sẽ làm việc trên dự án, cái gì họ ẽ làm (cấu trúc phân cấp chia s

nh ỏcông việc), khi nào họ ẽ ắt đầu làm việc trên dự án và khi nào họ ẽ ết thúc s b s k

toán để đưa nó vào mộ ịt l ch trình theo l ch th i gian Ngoài ra, d li u l ch s t các ị ờ ữ ệ ị ử ừ

trước và làm th nào công vi c có th chia nh vào l ch trình ế ệ ể ỏ ị

1996) có thể được dùng để ấ l y một ý tưởng thô c a th i gian lủ ờ ịch tổng c ng cộ ần thi t: ế

hay ngay cả 4.0 đểthay th cho giá trế ị 3.0 – ch bỉ ằng cách dùng th ta sử ẽ ấ th y nó như thế nào

b b qua b i ngay t ị ỏ ở ừ những người điều hành cấp cao

Xem xét công việc quản trị ự án và công việc đánh giá ịch trình, để ý rằcông việc đánh giá ịlch trình sẽ quan tâm đến vi c lên l ch trình ệ ị ở m c đ cao c a ứ ộ ủtoàn d án, còn nh ng tính toán chi tiự ữ ết hơn đòi hỏi các phụ thu c yế ố, đội ngũ ộ u t

16

hi n b i công việ ở ệc quả ị ựn tr d án

N u ế đánh giátheo biểu thức tính lịch trình ở trên, ta ần tính toán thời gian c

phát triển trước, m t bi u thộ ể ức cơ bản cho việc đánh giá ị lch trình của bất kỳ ạ ho t

động qu n lý là: ả

N l c / S ỗ ự ố nhân viên = Lượ ng th i gian ờ

i – tháng] Dùng biểu thức tổng quát này, một hoạt động mà yêu cầu 8 [ngườ

gian 2 tháng

8 [ngườ i – tháng] / 4 [ngườ i] = 2 [tháng]

Thực tế thì việc đánh giá ị l ch trình s khó ẽ hơn rất nhiều Nó liên quan đến nhiều yếu

t ố như:

- S ố trường hợp sử ụng hệ ống làm việc mỗi ngày, số ờ làm việc hiệu quả d th gi trong m i ỗ trường h p s d ng h th ng ợ ử ụ ệ ố

- Những gián đoạn như là du lịch, h i nghộ ị, đào tạo hay ngh ỉ ốm, …

- S ng vùng th i gian cho các d ố lượ ờ ự án đố ới các công ty đa quối v c gia

m i liên h ố ệ và được th c hi n theo s tinh t cự ệ ự ế ủa từng người qu n lý ả

1.2.4 Đánh giá về chi phí

Có nhiều yếu tố để quan tâm khi đánh giá chi phí tổng cộng của một dự

cho mục đích gặ ỡ p g hay ki m th , các giao ti p (thí dể ử ế ụ, các cuộc gọi điện thoại

17

bình t ng quát M t chi phí nhân công chuổ ộ ẩn xác hơn lấy k t quế ả ừ t vi c sử ụệ d ng lương nhân công rõ ràng cho mỗi v trí (thí d , v ị ụ ị trí kĩ thuật, qu n lý chả ất lượng,

bao nhiêu phần trăm của nỗ ự l c dự án tổng cộng cần được cấp phát cho mỗi vị trí Khi này d li u l ch s ho c các mô hình d li u công nghi p l i có th tr giúp ữ ệ ị ử ặ ữ ệ ệ ạ ể ợ

xuQua việc nghiên cứu 4 bước trong phép đánh giá như trên, đề ất một tiến trình cơ sở cho vi c ệ đánh giá công sức ph n m m c a d ầ ề ủ ựánnhư được mô t trong ả

sơ đồ ở Hình 1-2:

1.3 Một số phương pháp đánh giá công sức phần mềm

Kích cỡ ỗ ự , n l c,chi phí thực tế, …

Thu thập các yêu cầu ban đầu

Đánh giá nỗ ự l c

Đánh giá kích cỡ ả s n ph m ẩ

Đưa ra lị ch trình

Đánh giá chi phí

Phê duyệt k t qu ế ả đánh giá

D ữ liệu giá hiện thờ i

K ế t quả đánh giá được phê duyệt

Các tài nguyên sẵn có

D ữ liệu dự án lịch sử

Hình 1-2 Tiến trình cơ sở đánh giá công sức phần m m cề ủa dự án

18

đánh giá tài nguyên c n thi t trong d án ầ ế ự

Points Analysis)

nghi

c

- Xác định kích c x lý thông tin thô cỡ ử ủa hệ ố th ng

- Đánh giá Yế ố Độu t phức tạp Kĩ thuật của hệ thố ng

“trung b nh” hay “phì ức tạp” phụ thu c số lượộ ng phần tử ữ ệ d li u mỗi loại và các yếu

19

ph n ầ

j

i, ni, j * Wi, j

trong đó:

i : nhận các giá trị ừ 1 đến 5, đạ ệ t i di n cho 5 lo i chạ ức năng

B ả ng 1 - 1 Tính UFPs – kích cỡ ử x lý thông tin thô – trong FPA

Bước 2: Đánh giá ế ố độ ứ ạ ỹy u t ph c t p k thu t c a h th ng ậ ủ ệ ố

B ả ng 1 Mườ ốn Yếu tố kĩ thuậ - 2 i b t trong FPA

không xu ấ t hiệ n, không ảnh hưở ng = 0

ph ứ c tạp Kỹ thu ậ t (TCF – Technical Complexity Factor) Cụ thể, mứ ộc đ của

hưởng) đến 5 (ảnh hưởng m nh m khạ ẽ ắp nơi), như Bảng 2 2 Y- ếu t ph c t p ố Độ ứ ạ

Kĩ thuật được tính theo công th c: ứ

=

14 1

i F i

trong đó:

i F i là mức độ ảnh hưởng t ng c ng (total ổ ộDegree of Influence) c a 14 y u tủ ế ố, do đó công thức trên có th vi t l i thành: ể ế ạ

UFPs : s m chố điể ức năng chưa được điều chỉnh được tính t ừ bước 1

TCF : y u t phế ố độ ức tạp kĩ thuật được tính t ừ bước 2

a) Ưu điể m

th

người dùng cuối Do đó, phương pháp là độ ậc l p v m t công ngh , áp dề ặ ệ ụng phương pháp FPA không yêu c u 1 cách cầ ụ ể th nào c a vi c mô tủ ệ ả ệ ố h th ng hay phát triển

h th ng, ví d ệ ố ụ như, một phương pháp phân tích cụ ể th

cần có đặc tả yêu cầu người dùng, cho phép ực hiệ đánh giá công sức dự án ớth n s m,

h tr qu n tr d án ỗ ợ ả ị ự

FPA không thể được tính toán một cách tự động, trong quy trình tính toán ta

22

Việc đánh giá và cho điểm mức độ ph m vi nh c a 14 y u t ạ ả ủ ế ố kĩ thuật có v ẻkhá đơn sơ Việc xác định m c đ ứ ộ ảnh hưởng c a m i y u t ủ ỗ ế ố và cho điểm là đúng nhưng vấn đề là điểm c a các y u t có kho ng giá tr gi ng nhau v i giá tr nh ủ ế ố ả ị ố ớ ị ỏ

nhau, cụ thể, hai y u t có thế ố ể cùng ảnh hưởng su t trong quá trình xây d ng hố ự ệ

l mệ ức độ ảnh hưởng với điểm tr ng s lọ ố để ấy kết qu m ả điể ảnh hưởng của yế ốu t

th ng,

đội ngũ kĩ thuật cũng ảnh hưởng lên quá trình phát tri n h thể ệ ống, nhưng không

ngoài, t o thu n l i cho vi c nghiên cạ ậ ợ ệ ứu năng suất làm việc của mỗi đội phát triển

c thụ ể Điều này không có nhiều ý nghĩa, vì trong thực tế, các đội phát triển thường thay đổ ởi các d án, có m t s ự ộ ố lượng người đi và mộ ố lượng người đến, năng t s

su t c th cấ ụ ể ủa đội phát triển cũ không thể áp dụng cho đội phát triển mới

bây gi thì có nhiờ ều điểm không phù h p ợ

Các hệ ống bây giờ không chỉ ục vụ cho một nhu cầu đơn lẻ mà phục vụcho nhiều đối tượng Các nhu cầ ấu y có thể gi ng nhau hay khác nhau Hệ ốố th ng được chia thành các mô – đun và nh ng ph n giữ ầ ống nhau được s d ng l i ch ử ụ ạ ứ

chung th t s là m t vậ ự ộ ấn đề khó khăn Hơn nữa, m i mô ỗ – đun lại có m t k ch bộ ị ản riêng để ế ợ k t h p các chức năng lạ ới v i nhau

Với các hệ ố th ng gần đây hoạt động trên các hệ cơ sở ữ ệ d li u thì việc đếm s ố

23

lượng file logic là không h h p lý Các h cơ s d li u qu n lý các b ng d li u, ề ợ ệ ở ữ ệ ả ả ữ ệ

và như vậy đối tượng có th m là s ng các th c th ho c s ng các b ng ể đế ố lượ ự ể ặ ố lượ ả(lo i th c th ) ch không ph i là s ng các file logic trong thao tác cạ ự ể ứ ả ố lượ ủa hệ ả qu n

tr ị cơ sở ữ ệ d li u

liệu được lưu trữ Trong khi các ứng dụng khoa học và kĩ thuật phải giải quyết các

gi i qu t nh ng h thả ế ữ ệ ống như thế

l

Mô hình COCOMO là mô hình đánh giá giá cấu thành (nỗ ực và thời gian)

của phần mềm dựa trên đánh giá kích cỡ ủa chương trình được phân phối cho cngười dùng COCOMO được gi i thi u l n đớ ệ ầ ầu tiên năm 1981 trong cuốn sách Software Engineering Economics của tác giả Barry Boehm

a Mô hình COCOMO cơ sở (basic COCOMO)

- organic: cho những d ự án tương đối nh ỏ và đơn giản được phát tri n b i ể ở

24

cứng nhắc và có thể là linh động, do đó việc phát triể có thể được hỗ ợ ởi n tr b

nh ng d ữ ự án đã được thực hiện trước đó

- semi- detached: cho những d án có m c đ trung bình (v kích c ự ứ ộ ề ỡ và độ

s ố linh động, tức là dự án vẫn có thể được hỗ ợ ừ ững dự án trước đó tr t nhnhưng với mức độ ít

E : là n l c phát tri n d ỗ ự ể ự án theo đơn vị người – tháng,

T : là th i gian phát triờ ển dự án theo tháng,

P : là s ố người phát tri n, ể

a b , b b , c b , d b: là các hệ ố s theo kinh nghiệm được cho theo phương

th c phát tri n cứ ể ủa dự án như bảng sau:

B ả ng 1 - 3 Phân lo i ch phát tri ạ ế độ ể n sản phẩm trong COCOMO cơ sở

25

Mô hình COCOMO trung cấp là một sự ở ộng của mô hình cơ sở để

lo i lạ ại được phân chia thành các lo i con: ạ

Nhóm 3:Các thu c tính nhân l c ộ ự

- Kinh nghi m ng dệ ứ ụng

- Kinh nghi m ngôn ng l p trình ệ ữ ậ

Nhóm 4:Các thu c tính d ộ ựán

- Việc dựng c c công c ph n m m ỏ ụ ầ ề

- L ch trình phát triị ển được yêu c u ầ

Dựa trên việc xem xét tỉ ệ, một thừa số ỗ ực đượ l n l c xác định theo kinh nghiệm như

(EAF – Effort Adjust Factor) Giá tr cị ủa EAF dao động t 0.9 t i 1.4 ừ ớ

Công th ức:

i F i EAF

trong đó: EAF : Yế ố Điều t u ch nh N l c ỉ ỗ ự

F i : Y u t th i, có giá tr ế ố ứ ị như Bảng 1-4 Các thu c tính ộ

Nhân lực

D án ự

B ả ng 1 - 4 Các Y ế u tố điều chỉnh trong COCOMO trung c p ấ

27

E = a i * (KLOC)b i * EAF

trong đó:

EAF : là y u t u ch nh n lế ố điề ỉ ỗ ực được tính như ở trên

a i và b i : là các hệ ố được đưa ra như bả s ng sau:

B ả ng 1 - 5 Phân lo i ch phát tri n trong COCOMO trung c p ạ ế độ ể ấ

c Mô hình COCOMO nâng cao (advanded COCOMO)

Mô hình COCOMO nâng cao kết hợp tất cả các đặc tính của COCOMO

(phân tích, thi t k ,…) trong tiế ế ến trình kĩ nghệ ph n m m ầ ề

c th ụ ể như thế nào để ự động hóa quá trình đánh giá t

Các Yếu tố điều chỉnh là khá đầy đủ, có tính đến cả các yếu tố Nhân lực thực

giúp ích t t cho viố ệc đánh giá mức độ ảnh hưởng của mỗ ế ố để điềi y u t u ch nh giá ỉ

của dự án

chương trình sớm trong vòng đờ ải s n ph m là m t công viẩ ộ ệc khó khăn và có vẻ

28

hưởng r t lấ ớn đến s dòng lố ệnh Hơn nữa, ngày nay vi c xây d ng các giao di n ệ ự ệngười – máy cho h th ng nhệ ố ận đượ ự ỗ ợ ấ ớ ừc s h tr r t l n t nhi u công c kéo th giao ề ụ ả

con người vi t ế

Mô hình COCOMO chỉ quan tâm đến số lượng dòng lệnh để tính toán Tức

là với mộ ố lượt s ng dòng lệnh cho trước, dù là thuộc ngôn ng nào, s cho mữ ẽ ột giá

sản phẩm (nỗ ực và thời gian phát triển) cụ thể giá sản phẩ này có thể được điều l , m chỉnh b ng các yế ố điềằ u t u ch nh, thì giá tr đi u chỉ ị ề ỉnh là không đáng kể Điều này

là không hợp lý khi lượng tri thức chứa trong mộ ố lượt s ng dòng lệnh cho trước của các ngôn ng khác nhau là r t khác nhau, dữ ấ ẫn đến nỗ ự l c phát triển lượng dòng lệnh

khác nhau, tức là nỗ ự l c phát tri n khác nhau ể

nhưng lại có nh ng yêu c u kh t khe và d án ph i xây d ng m t cách c n th n t ữ ầ ắ ự ả ự ộ ẩ ậ ừ

đầu mà không nhận đượ ự ỗ ợ ừ ữ ệ ịc s h tr t d li u l ch s , gi ng v i ki u embedded ử ố ớ ể

1.3.3 1 Giới thiệu phương pháp

Trong giai đoạn phân tích, người sử dụng cộng tác cùng nhóm phát triển phần mềm tạo nên một tổ hợp thông tin quan trọng về yêu cầu đối với hệ thống Không chỉ là người cung cấp thông tin, bản thân người sử dụng còn là một thành phần hết sức quan trọng trong bức tranh toàn cảnh đó và nhóm phát triển cần phải chỉ ra được phương thức hoạt động của hệ thống tương lai theo hướng nhìn của người sử dụng Hiểu được điểm quan trọng này là chìa khóa để tạo dựng được những hệ thống vừa thoả mãn các yêu cầu đặt ra vừa dễ dàng sử dụng, thậm chí tạo niềm vui thích trong sử dụng

29

Như vậy công cụ giúp ta mô hình hoá hệ thống từ hướng nhìn của người sử dụng gọi là Use Case Tất cả chúng ta đều trải qua những kinh nghiệm khi quyết định mua một món hàng nào đó không phải vì niềm vui bộc phát Việc chúng ta sẽ làm trong những trường hợp như vậy là một dạng phân tích Use Case: Chúng ta tự hỏi mình sẽ sử dụng sản phẩm (hay hệ thống) sắp bắt ta bỏ ra một khoản tiền đáng

kể đó ra sao? Trả lời xong câu hỏi trên ta mới có khả năng chọn ra sản phẩm thoả mãn những đòi hỏi của mình Điều quan trọng ở đây là phải biết những đòi hỏi đó là

gì

Loại quy trình này đóng vai trò rất quan trọng đối với giai đoạn phân tích của một nhóm phát triển hệ thống Người dùng muốn sử dụng hệ thống tương lai, hệ thống mà bạn sắp thiết kế và xây dựng, như thế nào?

Use Case là một công cụ trợ giúp cho công việc của nhà phân tích cùng người sử dụng quyết định tính năng của hệ thống Một tập hợp các Use Case sẽ làm nổi bật một hệ thống theo phương diện những người dùng định làm gì với hệ thống này

Quá trình tương tác giữa người sử dụng và hệ thống trong mỗi một tình huống sẽ khác nhau và phụ thuộc vào chức năng mà người sử dụng muốn thực thi cùng hệ thống

Nhóm phát triển hệ thống cần phải xây dựng nên một kịch bản nêu bật sự tương tác cần thiết giữa người sử dụng và hệ thống trong mỗi khả năng hoạt động

Ví dụ như kịch bản cho sự tương tác giữa nhân viên thu ngân và hệ thống của bộ phận tiết kiệm trong suốt tiến trình của một giao dịch Một kịch bản khác ví dụ là chuỗi tương tác xảy ra giữa bộ phận tiết kiệm và bộ phận đầu tư trong một giao dịch chuyển tiền

Nhìn chung, có thể coi một Use case như là tập hợp của một loạt các cảnh kịch về việc sử dụng hệ thống Mỗi cảnh kịch mô tả một chuỗi các sự kiện Mỗi một chuỗi này sẽ được kích hoạt bởi một người nào đó, một hệ thống khác hay là một phần trang thiết bị nào đó, hoặc là một chuỗi thời gian Những thực thể kích hoạt nên các chuỗi sự kiện như thế được gọi là các Tác Nhân (Actor) Kết quả của

30

chuỗi này phải có giá trị sử dụng đối với hoặc là tác nhân đã gây nên nó hoặc là một tác nhân khác

1.3.3 2 Sự cần thiết phải sử dụng Use Case

Use Case là một công cụ xuất sắc để khuyến khích những người dùng tiềm năng nói về hệ thống từ hướng nhìn của họ Đối với người dùng, chẳng phải bao giờ việc thể hiện và mô tả những ý định trong việc sử dụng hệ thống cũng là chuyện dễ dàng Một hiện thực có thật là người sử dụng thường biết nhiều hơn những gì mà họ

có thể diễn tả ra: Công cụ Use Case sẽ giúp cho nhóm phát triển bẻ gãy "lớp băng"

đó, ngoài ra một sự trình bày trực quan cũng cho phép bạn kết hợp các biểu đồ Use Case với các loại biểu đồ khác

Sáng kiến chủ đạo là lôi cuốn được người dùng tham gia vào những giai đoạn đầu tiên của quá trình phân tích và thiết kế hệ thống Việc này sẽ nâng cao xác suất cho việc hệ thống chung cuộc trở thành một công cụ quen thuộc đối với các

của các khái niệm máy tính mà người dùng trong giới doanh thương có cảm giác

Công tác lôi kéo người sử dụng tham gia tích cực vào quá trình phân tích là nền tảng quan trọng cho việc tạo dựng một mô hình "thành công", một mô hình dễ được người sử dụng hiểu và chấp nhận sau khi đã thẩm xác các nhiệm vụ căn bản Ngoài ra, Use Case còn giúp nhóm phát triển quyết định các lớp mà hệ thống phải triển khai

1.3.3.3 Mô hình hóa Use Case

Trường hợp sử dụng là một kỹ thuật mô hình hóa được sử dụng để mô tả một

Use Case được xây dựng qua một quá trình mang tính vòng lặp (interative), trong

đó những cuộc hội thảo bàn luận giữa nhóm phát triển hệ thống và khách hàng (hoặc/và người sử dụng cuối) sẽ dẫn tới một đặc tả yêu cầu được tất cả mọi người chấp nhận Người cha tinh thần của mô hình hóa Use Case là Ivar Jacobson, ông đã tạo nên kỹ thuật mô hình hóa dựa trên những kinh nghiệm thu thập được trong quá

31

trình tạo hệ thống AXE của hãng Erisson Use Case đã nhận được một sự quan tâm đặc biệt lớn lao từ phía cộng đồng hướng đối tượng và đã tác động lên rất nhiều phương pháp hướng đối tượng khác nhau

Những thành phần quan trọng nhất của một mô hình là Use Case, tác nhân và

hệ thống Ranh giới của hệ thống được định nghĩa qua chức năng tổng thể mà hệ thống sẽ thực thi Chức năng tổng thể được thể hiện qua một loạt các Use Case và mỗi một Use Case đặc tả một chức năng trọn vẹn, có nghĩa là Use Case phải thực thi toàn bộ chức năng đó, từ sự kiện được kích hoạt đầu tiên bởi một tác nhân ngoại cảnh cho tới khi chức năng đòi hỏi được thực hiện hoàn tất Một Use Case luôn luôn phải cung cấp một giá trị nào đó cho một tác nhân, giá trị này là những gì mà tác nhân mong muốn từ phía hệ thống Tác nhân là bất kỳ một thực thể ngoại cảnh nào mong muốn tương tác với hệ thống Thường thường, đó là một người sử dụng của

hệ thống, nhưng nhiều khi cũng có thể là một hệ thống khác hoặc là một dạng máy móc thiết bị phần cứng nào đó cần tương tác với hệ thống

Trong kỹ thuật mô hình hóa Use Case, hệ thống sẽ có hình dạng của một

"hộp đen" và cung cấp các Use Case Hệ thống làm điều đó như thế nào, các Use Case được thực thi ra sao, đó là những khía cạnh chưa được đề cập tới trong giai đoạn này Trong thực tế, nếu mô hình hóa Use Case được thực hiện trong những giai đoạn đầu của dự án thì thường nhà phát triển sẽ không biết Use Case sau này sẽ được thực thi (tức là biến thành những dòng code thật sự) như thế nào

Mục tiêu chính yếu đối với các Use Case là:

- Để quyết định và mô tả các yêu cầu về mặt chức năng của hệ thống, đây là kết quả rút ra từ sự thỏa thuận giữa khách hàng (và/hoặc người sử dụng cuối) và nhóm phát triển phần mềm

- Để tạo nên một lời mô tả rõ ràng và nhất quán về việc hệ thống cần phải làm gì, làm sao để mô hình có thể được sử dụng nhất quán suốt toàn bộ quá trình phát triển, được sử dụng làm công cụ giao tiếp cho tất cả những người phát triển nên các yêu cầu này, và để tạo nên một nền tảng cho việc tạo nên các mô hình thiết

kế cung cấp các chức năng được yêu cầu

Những công việc cụ thể cần thiết để tạo nên một mô hình Use Case bao gồm:

1 Định nghĩa hệ thống (xác định phạm vi hệ thống)

2 Tìm ra các tác nhân cũng như các Use Case

4 Định nghĩa mối quan hệ giữa các Use Case

5 Kiểm tra và phê chuẩn mô hình

Đây là một công việc mang tính tương tác rất cao, bao gồm những cuộc thảo luận với khách hàng và những người đại diện cho các loại tác nhân Mô hình Use Case bao gồm các biểu đồ Use Case chỉ ra các tác nhân, Use Case và mối quan hệ của chúng với nhau Các biểu đồ này cho ta một cái nhìn tổng thể về mô hình, nhưng những lời mô tả thực sự của từng Use Case thường lại là văn bản Vì các mô hình trực quan không thể cung cấp tất cả các thông tin cần thiết, nên cần thiết phải dùng cả hai kỹ thuật trình bày đó

Có rất nhiều người quan tâm đến việc sử dụng các mô hình Use Case Khách hàng (và/hoặc người sử dụng cuối) quan tâm đến chúng vì mô hình Use Case đặc tả chức năng của hệ thống và mô tả xem hệ thống có thể và sẽ được sử dụng ra sao Các Use Case vì vậy phải được mô tả trong những thuật ngữ và ngôn ngữ của khách hàng/người sử dụng

33

Nhà phát triển cần đến các mô hình Use Case để hiểu hệ thống cần phải làm gì, và qua đó có được một nền tảng cho những công việc tương lai (các mô hình khác, các cấu trúc thiết kế và việc thực thi xây dựng hệ thống bằng code)

Các nhóm chuyên gia thử nghiệm tích hợp và thử nghiệm hệ thống cần đến Use Case để thử nghiệm và kiểm tra xem hệ thống có đảm bảo sẽ thực hiện đúng chức năng đã được đặc tả trong giai đoạn đầu

Và cuối cùng, bất kỳ người nào liên quan đến những hoạt động liên kết đến chức năng của hệ thống đều có thể quan tâm đến các mô hình Use Case; ví dụ như các nhóm tiếp thị, bán hàng, hỗ trợ khách hàng và các nhóm soạn thảo tài liệu

1.4 Kết chương

Với tiêu chí là cung cấp một cách nhìn tổng quan về công tác đánh giá công sức trong quản lý dự án phần mềm với các khái niệm và các bước cơ bản, bắt buộc đối với quá trình đánh giá công sức phần mềm Trên cơ sở đó, tiến hành giới thiệu 3 phương pháp đánh giá công sức phần mềm đã được sử dụng bao gồm:

Trên cơ sở phân tích nội dung, qui trình tiến hành của từng phương pháp đề rút ưu, khuyết điểm của từng phương pháp, tiến hành lựa chọn một phương pháp được xác định là có nhiều ưu điểm nhất hiện nay, đó là phương pháp đánh giá công

Mô hình Use Case mô tả hướng nhìn Use Case của hệ thống Hướng nhìn này là rất quan trọng, bởi nó ảnh hưởng đến tất cả các hướng nhìn khác của hệ thống Cả cấu trúc logic lẫn cấu trúc vật lý đều chịu ảnh hưởng từ các Use Case, bởi chức năng được đặc tả trong mô hình này chính là những chức năng được thực thi trong các cấu trúc kia Mục đích cuối cùng là thiết kế ra một giải pháp thỏa mãn các yêu cầu đó

Với những đặc tính ưu việt của phương pháp này, Bộ Thông tin và Truyền

Trong khuôn khổ đề tài, Chương 2 sẽ tập trung phân tích phương pháp xác định giá trị phần mềm theo hướng tiếp cận điểm chức năng theo quan điểm người

sử dụng Use Case Points

35

Chương 2 PHƯƠNG PHÁP ĐÁNH GIÁ CÔNG SỨC PHẦN MỀM SỬ DỤNG HƯỚNG TIẾP CẬN ĐIỂM CHỨC NĂNG SỬ DỤNG (Use Case Point Analysis)

2.1 Tổng quan phương pháp đánh giá công sức dự án theo điểm Use Case (Use Case Points)

Vào đầu những năm 1990, James Rambough, Grady Booch và Ivar Jacobson

đã nghiên cứu và xây dựng nên những thành phần của phương pháp kĩ nghệ phần

đã ra đời có các kí pháp và phương thức phục vụ cho việc phát triển phần mềm

Unified Process) UML xác định các yêu cầu cho sản phẩm phần mềm với các trường hợp sử dụng hệ thống

lược và các kịch bản chi tiết thực hiện trên lĩnh vực nghiệp vụ, nên chúng cũng có thể cung cấp cái nhìn vào tính phức tạp của một ứng dụng Thu được một kết quả đánh giá tin cậy của cỡ và nỗ lực mà một ứng dụng cần, là có thể bằng cách xem xét

án Năm 1993, Gustav Karner đã sáng tạo ra kĩ thuật đánh giá công sức dự

phân tích các tác nhân, các kịch bản và các yếu tố môi trường và kĩ thuật và đưa chúng vào một phương trình Đây là một kĩ thuật đánh giá công sức dự án tốt khi phát triển dự án theo phương pháp hướng đối tượng nhưng chưa được phổ biến Đó

là bởi vì phương pháp Hướng đối tượng chỉ thực sự trở thành phổ biến trong những năm gần đây và các phương pháp đánh giá cũ đó quá nổi tiếng trong ngành công nghiệp phần mềm

36

Kĩ thuật đánh giá của Karner hiện nay đã được đưa vào RUP, ([1] Carroll, 2005) Gần đây một số đội kĩ nghệ của sự phối hợp của Agilis Solutions và FPT Software, Hanoi, Vietnam, đã áp dụng phương pháp của Karner và đưa ra được những kết quả đánh giá đáng tin cậy sớm trong vòng đời dự án

Tóm tắt về Use Case

Mô hình Use Case là một kỹ thuật được sử dụng để miêu tả những yêu cầu mang tính chức năng của một hệ thống Use Case được miêu tả qua các khái niệm tác nhân bên ngoài, Use Case và hệ thống Tác nhân tượng trưng cho một vai trò và một thực thể bên ngoài ví dụ như một người dùng, một bộ phận phần cứng hoặc một hệ thống khác tương tác với hệ thống Tác nhân gây ra và giao tiếp với các Use Case, trong khi một Use Case là một tập hợp của các chuỗi hành động được thực hiện trong hệ thống Một Use Case phải cung cấp một giá trị cần hướng tới nào đó cho tác nhân, và bình thường nó được miêu tả bằng văn bản Tác nhân và Use Case

là các lớp Một tác nhân được liên kết với một hoặc nhiều Use Case qua mối liên kết (Association) và cả tác nhân lẫn Use Case đều có thể có mối quan hệ khái quát hóa, mối quan hệ này miêu tả những ứng xử chung trong các lớp cha, sẽ được thừa

kế bởi một hoặc nhiều lớp con Một mô hình Use Case được miêu tả bằng một hay nhiều biểu đồ trường hợp thuộc ngôn ngữ UML

Use Case được thực hiện qua các sự cộng tác Một sự cộng tác là một lời miêu tả một ngữ cảnh, chỉ ra các lớp/ đối tượng và mối quan hệ của chúng và một tương tác chỉ ra các lớp/đối tượng đó tương tác với nhau ra sao để thực hiện một chức năng cụ thể Một sự cộng tác được miêu tả bằng biểu đồ hoạt động, biểu đồ cộng tác và biểu đồ chuỗi Khi một Use Case được thực hiện, trách nhiệm cho mỗi bước hành động trong Use Case cần phải được phân bổ cho các lớp tham gia sự cộng tác đó, thường là qua việc xác định các thủ tục của các lớp này, đi song song với phương thức mà chúng tương tác với nhau Một cảnh kịch là một thực thể của một Use Case, hay một sự cộng tác, chỉ ra một chuỗi thực thi cụ thể Vì thế, một cảnh kịch là một sự minh họa hay là một ví dụ của một Use Case hay là một sự cộng tác Khi cảnh kịch được chỉ ra trong tư cách một thực thể của một Use Case,

37

chỉ duy nhất sự tương tác giữa Use Case và tác nhân ngoại lai sẽ được miêu tả, nhưng khi cảnh kịch được quan sát và được chỉ ra theo hướng là một thực thể của một sự cộng tác, thì sự tương tác giữa các lớp/đối tượng phía bên trong hệ thống cũng sẽ được miêu tả

2.1.1 Các khái niệm

2.1 1.1 Biểu đồ Use Case

Một biểu đồ Use Case chứa các phần tử mô hình biểu thị hệ thống, tác nhân cũng như Use Case và chỉ ra các mối quan hệ giữa các Use Case

Lời mô tả nội dung Use Case thường được cung cấp dưới dạng văn bản Lời

mô tả đó được coi là thuộc tính "văn bản" (document) của Use Case Lời mô tả này bao chứa những thông tin quan trọng, định nghĩa các yêu cầu và chức năng cụ thể Thay cho việc mô tả Use Case bằng văn bản, bạn cũng có thể vẽ một biểu đồ hoạt

dễ hiểu và dễ giao tiếp đối với người sử dụng, mà những cấu trúc phức tạp như một biểu đồ hoạt động có thể gây cảm giác xa lạ đối với những người không quen sử dụng

Một biểu đồ Use Case thể hiện:

38

Trong đó :

2.1.1.2 Hệ thống

Vì hệ thống là một thành phần của mô hình Use Case nên ranh giới của hệ

phải bao giờ cũng nhất thiết là một hệ thống phần mềm; nó có thể là một chiếc máy, hoặc là một doanh nghiệp Định nghĩa các ranh giới và trách nhiệm của hệ thống không phải bao giờ cũng là việc dễ dàng, bởi không phải bao giờ người ta cũng rõ

Hi n th c nh 3 ể ị ảchi u khu về ực tậ p

T o hi u ng ạ ệ ứsóng, gió, l c ắ

Điều khiển tàu đi

bi n theo bài t p ể ậ

thao tác trên trang thi t b hàng h i ế ị ả

T H Ổ Ợ P MÔ PHỎNG ĐIỀ U KHI N TÀU BI N Ể Ể

Hình 2 1 Một ví dụ biểu đồ Use case

39

ràng nhìn ra tác vụ nào có khả năng được tự động hóa tốt nhất ở hệ thống này và tác

vụ nào thì tốt nhất nên thực hiện thủ công hoặc dành cho các hệ thống khác Một khía cạnh khác cần chú ý là hệ thống cần phải lớn tới mức độ nào trong phiên bản đầu tiên của nó Cố gắng tối đa cho phiên bản đầu tiên của hệ thống thường là cách

mà người ta hay thực hiện, thế nhưng những mục tiêu quá tầm như vậy có thể khiến cho hệ thống trở nên quá lớn và thời gian để cung cấp hệ thống quá lâu Một sáng kiến tốt hơn là xác nhận cho rõ các chức năng căn bản và tập trung vào việc định nghĩa một kiến trúc hệ thống thích hợp, rõ ràng, có nền tảng rộng mở để nhiều chức năng hơn có thể được bổ sung vào hệ thống này trong các phiên bản sau

Yếu tố quan trọng là phải tạo dựng được một bản danh mục các khái niệm (các thực thể) trung tâm cùng với các thuật ngữ và định nghĩa thích hợp trong những giai đoạn đầu của thời kỳ phân tích Đây chưa phải mô hình phạm vi đối tượng, mà đúng hơn là một cố gắng để mô tả các thuật ngữ của hệ thống hoặc doanh nghiệp mà chúng ta cần mô hình hóa Các thuật ngữ sau đó sẽ được dùng để mô tả

là một mô hình khái niệm chỉ ra các mối quan hệ đơn giản hoặc chỉ là một văn bản chứa các thuật ngữ cùng lời mô tả vắn tắt những thuật ngữ này trong thế giới thực

2.1.1.3 Tác nhân

Một tác nhân là một người hoặc một vật nào đó tương tác với hệ thống, sử dụng hệ thống Trong khái niệm "tương tác với hệ thống", ý chúng ta muốn nói rằng tác nhân sẽ gửi thông điệp đến hệ thống hoặc là nhận thông điệp xuất phát từ hệ thống, hoặc là thay đổi các thông tin cùng với hệ thống Nói một cách ngắn gọn, tác nhân thực hiện các Use Case Thêm một điều nữa, một tác nhân có thể là người mà cũng có thể là một hệ thống khác (ví dụ như là một chiếc máy tính khác được nối kết với hệ thống của chúng ta hoặc một loại trang thiết bị phần cứng nào đó tương tác với hệ thống)

Một tác nhân là một dạng thực thể (một lớp), chứ không phải một thực thể Tác nhân mô tả và đại diện cho một vai trò, chứ không phải là một người sử dụng