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

Tổng quan công tác đánh giá công sức trong quản lý dự án phần mềm. 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. 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. 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.

B Ộ GIÁO DỤC VÀ ĐÀO TẠO

-

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

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

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

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

1.3.1 Phương pháp phân tích Điểm Chức năng nghiệp vụ 18 1.3.2 Mô hình đánh giá giá cấu thành (COCOMO) 23 1.3.3 phương pháp đánh giá công sức dự án theo Use Case 28

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

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

2.1.2 Phương pháp xác định Tác nhân và Use Case 42 2.1.3 Quan h ệ giữa các Use Case 47

2

2.2 Xác định giá trị phần mềm bằng phương pháp tính điểm Use Case 55

2.2.1 T ổng quát về xác định giá trị phần mềm 55 2.2.2 Tính s ố điểm Use Case sau hiệu chỉnh (AUCP) 56 2.2 3 Đánh giá nỗ lực từ số Use Case 70 2.2.4 T ổng hợp giá trị phần mềm 71

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

3.5.1 Phân tích bài toán để xây dựng cơ sở dữ liệu 80 3.5.2 Xây d ựng biểu dồ thực thể - liên kết (E-R) 81 3.5.3 Xây d ựng lược đồ quan hệ 84

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.1 Đánh giá công sức phần mềm dự án xây dựng phòng mô phỏng ĐKTB 86

4.1.1 S ắp xếp thứ tự ưu tiên các yêu cầu chức năng phần mềm 87 4.1.2 Chuy ển đổi yêu cầu chức năng sang USE-CASE 94

4.2.2 So sánh UCP v ới COCOMO 105

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ếu tố kĩ thuậ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ố điểm Use Case trong UCP 61

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ếu tố Độ phức tạp Kĩ thuậ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ếu tố Độ phức tạp Môi trườ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 Đồ thị hội tụ đánh giá Độ 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 đồ hoạt động của Use Case"Thực hiện đánh giá mới dự án" 76

Hình 3 3 Biểu đồ hoạt độ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ới" 77

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 đồ tuần tự 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

COCOMO : COnstructive COst MOdel – Mô hình giá cấu thành

EAF : Effort Adjust Factor – yếu tố điều chỉnh nỗ lực

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

FP : Function Point – Điểm chức năng

UFP : Unadjusted Function Point – Điểm Chức năng chưa được điều chỉnh FPA : Function Point Analysis – Phân tích điểm chức năng

FPs : Function Points – số Điểm chức năng

UCP : Use Case Point – Điểm chức năng sử dụng

UCPs : Use Case Points – số Điểm chức năng sử dụng

UML : Unified Modelling Language – ngôn ngữ mô hình hóa thống nhất AUCP : Adjusted Use Case Point - Điểm chức năng sử dụng sau hiệu chỉnh UUCP : Unadjusted Use Case Point – Điểm chức năng sử dụng chưa được

điều chỉnh UUCPs : Unadjusted Use Case Point – số Điểm ca sử dụng chưa được điều

chỉnh TAW : Total Actors Weighted– Tổng số Tác nhân sau khi đánh trọng số TBW : Tổng số chức năng sử dụng sau khi đánh trọng số

TCF : Technical Complexity Factor – Yếu tố độ phức tạp kĩ thuật

ECF : Environmental Complexity Factor – Yếu tố độ phức tạp môi trường

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

Các phương pháp truyền thống thường là không tin cậy hoặc là yêu cầu quá nhiều các thao tác đo, tính toán phức tạp Hơn nữa, do bộ dữ liệu thử nghiệm quá

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

Việc nghiên cứu, hoàn thiện các phương pháp dự báo và đánh giá công sức

phần mềm mang tính thực tiễn cao và có ý nghĩa rất lớn trong quản lý các dự án

phần mềm

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

Nghiên cứu và kế thừa một số phương pháp dự báo, đánh giá công sức, nguồn lực trong quản lý dự án phần mềm ở Việt Nam và trên thế giới Tập hợp và 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

chọn phương pháp điểm chức năng sử dụng (Use Case Point) để đánh giá công sứ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ế việc sử dụng phương pháp trong tính toán các dự án

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:

Đề tài tập trung giải quyết các vấn đề sau

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 giá công sức, nguồn lực phần mềm đã và đang được nghiên cứu ứng dụng

3.2 Tiến hành So sánh, lựa chọn mô hình đánh giá, dự đoán công sức phần

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ô hình hiện có Phân tích đánh giá công sức phần mềm trong các phương pháp phát triển phần mềm đã biết, từ đó, lựa chọn mô hình phù hợp để ứng dụng Tập trung vào phương pháp đánh giá điểm chức năng Use-Case Point (UCP)

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, độ chính xác và ưu, nhược điểm của các thông số áp dụng trên mô hình đã chọn

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

Chương 1 : Tổng quan về đánh giá công sức và nguồn lực trong quản lý Dự

án phần mềm

Chương 2 : Phương pháp điểm chức năng UCP (Use Case Point)

Chương 3 : Xây dựng công cụ hỗ trợ phương pháp điểm chức năng UCP 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

Kết luận

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

chế nên không thể 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ôi xin chân thành cảm

ơn sự hướng dẫn, giúp đỡ tận tình của thầy hướng dẫn, PGS.TS Hu ỳ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 đỡ tôi trong quá trình học tập cũng như trong quá trình làm

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

dự án một cách hiệu quả: Sẽ không thể lập được kế hoạch và điều khiển dự án có

hiệu quả nếu không có một qui trình tính toán công sức phần mềm đầy đủ và đáng 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

việc áp dụng một qui trình tính toán công sức không đầy đủ, thiếu chính xác và khoa học

Cho đến bây giờ cũng dễ nhận thấy rằng ngành công nghiệp phần mềm nói chung không có nhiều các phương pháp tốt để đánh giá công sức phần mềm của dự

án Hình 1-1, tham khảo từ tài liệu ([6] McConnell, 1996) thể 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ế,

việc đánh giá chỉ được chính xác hóa dần dần trong quá trình làm mịn dần dự án

Từ hình vẽ có thế nhận thấy rằng để đưa ra được các đánh giá đáng tin cậy và sớm 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

Đánh giá không đầy đủ công sức phần mềm của một dự án dẫn đến

(a) việc bố trí thiếu cho dự án (điều mà thường dẫn đến việc vượt quá khả năng làm việc),

(b) quản lý thiếu các nỗ lực đảm bảo chất lượng (bỏ sót các nguy cơ rủi ro

của sản phẩm kém chất lượng), và

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)

Còn đối với những người mà mong muốn tránh khỏi tình huống này bằ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

dự án có thể chỉ làm tồi tệ cho tổ chức Nếu như đưa cho một dự án nhiều tài nguyên hơn mức nó thực sự cần mà không có những điều hành phạm vi đầy đủ, nó

sẽ bị dùng hết Điều này giống như là quy tắc Parkinson được mô tả trong bài viết

([10] What Is Parkinson’s Law in Project Management?, 2010): “Work expands so

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

Ngu ồn tham khảo: ([6] McConnell 1996)

11

as to fill the time available for its completion” tạm dịch là:“Công việc mở rộng để

lấp đầy thời gian có sẵn để hoàn thành”

Dự án khi đó có khả năng phải

(a) chi phí nhiều hơn mức cần thiết (một tác động tiêu cực đến tài chính và

có thể làm giảm lợi thế cạnh tranh),

(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ó bốn bước chính trong đánh giá công sức dự án phần mềm là:

1 Đánh giá ph ạm vi của sản phẩm phát triển Thông thường, điều này luôn

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

lệnh (LOC – line of code) hoặc điểm chức năng (FP – Function Point) Trong khi kích cỡ theo LOC là đơn vị kích cỡ cơ sở được dùng bởi nhiều mô hình tính toán đánh giá hàng đầu, nhiều đội phát triển lại không thích với những phép đo này và dùng những đơn vị ít chính quy hơn (số đặc tính, số yêu cầu thay đổi, số trường hợp

sử dụng / số kịch bản, số tường thuật người dùng, số phát biểu yêu cầu, …) Một

thảo luận về các ưu điểm và nhược điểm của các phương pháp đo kích cỡ khác nhau

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

2 Đánh giá n ỗ lực theo đơn vị [người – tháng] hoặc [người – giờ] dùng một

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

3 Đánh giá l ịch trình theo lịch thời gian (tháng/tuần) Điều này có thể được

tính toán từ nỗ lực được đánh giá và là mộ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à ở

một số điểm trong lịch trình dự án không thể rút ngắn lịch trình bằng cách thêm tài nguyên cho việc phát triển

4 Đánh giá chi phí dự án theo đơn vị tiền tệ Điều này là một kết hợp của

giá nhân công (cái mà có thể được tính toán từ ước lượng nỗ lực) và giá phi nhân

của dự án nên được thu thập bất cứ nơi nào có thể, bắt đầu với những mô tả chính

thức của các yêu cầu Không nên để cho sự thiếu sót về đặc tả phạm vi làm cản trở

việc thực hiện ước lượng Tài liệu đánh giá cũng không nên chốt cứng Trong mọi 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 cho dự án ngay khi có thêm thông tin phạm vi được xác định Nếu chúng ta thực

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ử dụng để cung cấp thêm thông tin chi tiết

Hai cách để có thể đánh giá kích cỡ sản phẩm là:

1 Cách thứ nhất: bằng phép tương tự Nếu chúng ta đã hoàn thành một dự

á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, chúng ta có thể đánh giá mỗi phần chính của của dự án mới như là một phép tính

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

của dự án mới bằng cách cộng lại các kích cỡ được đánh giá của mỗi phầ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

hợp sử dụng/ kịch bản, các yêu cầu người dùng) và đếm chúng Một số người dùng

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

hoặc chúng ta có thể chuyển chúng thành một đơn vị đo kích cỡ chính thức mà ta

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

Một người có kinh nghiệm có thể đưa ra những đánh giá kích cỡ tốt, hợp lý

bằng phép tương tự nếu sẵn có các giá trị kích cỡ chuẩn xác cho dự án trước và dự

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

13

2 Cách thứ hai: bằng phép phân tích bằng cách đếm các đặc điểm sản

phẩm và dùng một phương pháp thuật toán như là Điểm Chức năng (FP) chúng ta

có thể chuyển phép đếm thành một ước lượng của kích cỡ

Các đặc tính sản phẩm ở cấp độ vĩ mô có thể chứa số lượng các hệ thống con, các lớp/ mô – đun, các phương thức/ hàm Các đặc tính sản phẩm ở mức chi

tiết hơn có thể gồm có số lượng các màn hình, các hộp thoại, các file, các bảng 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ó kết quả đánh giá về kích cỡ của sản phẩm, chúng ta có

thể tính toán đánh giá nỗ lực từ nó Việc chuyển đổi từ kích cỡ phần mềm sang nỗ

lực dự án tổng cộng chỉ có thể làm được nếu chúng ta có một vòng đời phát triển

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

Một dự án phát triển phần mềm đòi hỏi nhiều hơn công việc viết mã phần

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ể nỗ lực

dự án Việc viết và thẩm định tài liệu, thi hành các bản mẫu, thiết kế các phiên bản

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á nỗ lực dự án yêu cầu ta xác định và tính toán, sau đó tổng hợp

lại tất cả các hoạt động ta phải thực hiện để xây dựng một sản phẩm từ kích cỡ được đánh giá

Hai cách có thể dùng để tính toán nỗ lực từ kích cỡ:

1 Cách thứ nhất: dùng d ữ liệu lịch sử - là dùng dữ liệu lịch sử của chính tổ

chức để xác định bao nhiêu nỗ lực theo kích cỡ đã được đánh giá mà các dự án trước dùng đến Một sơ đồ tính toán mà liên hệ kích cỡ của sản phẩm và năng

suất của đội phát triển với nỗ lực dự án được đánh giá được sử dụng thường xuyê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ả thực tế từ các dự án 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ử dụng mộ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 các kĩ năng và kinh nghiệm tương tự cho dự án mới

2 Cách thứ hai: ti ếp cận thuật toán - nếu chúng ta không có dữ liệu lịch sử

của chính tổ chức bởi vì chúng ta chưa bắt đầu thu thập số liệu hoặc vì dự án mới là

rất khỏc, Chúng ta có thể sử dụng một cách tiếp cận thuật toán đã hoàn thiện và đã được công nhận rộng rãi (ví dụ mô hình COCOMO của Barry Boehm) để chuyển

một đánh giá kích cỡ thành một đánh giá nỗ lực Các mô hình này có được từ việc 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ử

của chính tổ chức của chúng ta, nhưng chúng có thể cho chúng ta những đánh giá

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

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

Như đã đề cập, nhiều tổ chức trong nền công nhiệp phần mềm không thấy thoải mái với khái niệm đánh giá kích cỡ sản phẩm Không phải là lạ khi nhìn thấy

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

việc đánh giá kích cỡ Trong khi điều này hoàn toàn có thể làm được, nó cũng nảy sinh vấn đề Các đánh giá trực tiếp tới nỗ lực đã ngầm giả định năng suất của đội phát triển cụ thể Khi đó nế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á phải đượ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

Bước thứ ba trong đánh giá công sức của một dự án phát triển phần mềm là xác định lịch trình dự án từ các đánh giá nỗ lực Điề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ọ sẽ làm (cấu trúc phân cấp chia

nhỏ công việc), khi nào họ sẽ bắt đầu làm việc trên dự án và khi nào họ sẽ kết thúc (gọi là “mô tả biên chế”) Một khi chúng ta có thông tin này, chúng ta cần tính 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

dự án trong quá khứ của tổ chức hoặc các mô hình dữ liệu công nghiệp có thể được

sử dụng để dự đoán số lượng người mà chúng ta cần cho một dự án với kích cỡ cho trước và làm thế nào công việc có thể chia nhỏ vào lịch trình

Nếu chúng ta không có gì, một quy tắc đánh giá lịch trình ([6] McConnell, 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:

L ịch Trình theo Tháng = 3.0 * ( nỗ lực[người – tháng] ) 1/3

Thí dụ, nếu chúng ta đã đánh giá được công sức của một dự án cần nỗ lực 65 [người – tháng], biểu thức trên cho thấy rằng cần lịch trình 12 tháng (3.0 * 651/3), từ

đó suy đội dự án có 5 hoặc 6 thành viên (65 /12)

Trong ([6] McConnell 1996) có nêu vấn đề nhiều đề xuất dùng 2.0 hay 2.5 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

Đánh giá lịch trình dự án là một chủ đề rắc rối bởi vì hầu hết các dự án thường bị chậm trễ Sự chậm trễ do nhiều nguyên nhân Các yêu cầu được phát hiện

dần dần không được quản lý chủ động Việc điều khiển chất lượng sản phẩm từ sớm thường không được chú trọng, dẫn đến dự án sẽ bị chậm trễ khi kiểm thử bắt đầu Ở

những tổ chức chưa có quy trình làm việc chuẩn thì những dự thảo lịch trình thường

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ị dự án và công việc đánh giá lịch trình, để ý rằng công việc đánh giá lịch 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ếu tố, đội ngũ

16

nhân viên sẵn có, và mức độ tài nguyên, phân công cho từng người sẽ được thực

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 cần tính toán thời gian

lịch trình trước rồi mới chỉ định số nhân viên Nhưng nếu được chỉ định một đội phát triển trước, một biểu thức cơ bản cho việc đánh giá lịch 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

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

của nỗ lực và có 4 người được chỉ định tham gia có thể được hoàn thành trong thời 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ư:

- Các phụ thuộc của một hoạt động với các hoạt động trước

- Các hoạt động đan xen hay đồng thời

- Đường găng xuyên suốt chuỗi công việc

- Số trường hợp sử dụng hệ thống làm việc mỗi ngày, số giờ làm việc hiệu quả 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ố lượng vùng thời gian cho các dự án đối với các công ty đa quốc gia

Như vậy công việc quản trị dự án và công việc đánh giá lịch trình có nhiều

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ự án Bao gồm giá nhân công, giá mua hay giá thuê phần cứng và phần mềm, việc đi lại 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 đường dài, hội thảo video từ xa, …), các khóa đào tạo, không gian văn phòng, …

Giá nhân công thì có thể được xác định một cách đơn giản nhất bằng phép nhân kết quả đánh giá nỗ lực của dự án (theo giờ) với lương nhân công tính trung

Qua việc nghiên cứu 4 bước trong phép đánh giá như trên, đề xuấ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ự án như đượ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

Đã có một số phương pháp được đề xuất cho việc đánh giá để hỗ trợ quản trị

dự án, trong số đó 2 phương pháp nổi tiếng nhất là phương pháp Phân tích Điể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á

Phát tri ển sản phẩm Phân tích ti ến trình đá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

Nguồn tham khảo: ([3] Hewson, 2007)

18

Chức năng (FPA - Function Point Analysis), mô hình Giá Cấu thành COCOMO (Constructive Cost Model) và phương pháp phân tích Use Case hệ thống (Use Case Point BMT Analysis) Ba phương pháp này còn có thể được kết hợp cùng nhau để đánh giá tài nguyên cần thiết trong dự án

1.3.1 Phương pháp phân tích Điểm Chức năng nghiệp vụ (FPA – Function Points Analysis)

1.3.1.1 Tóm lược

Phân tích Điểm Chức năng nghiệp vụ (FPA) là một phương pháp đo kích cỡ

của phần mềm mà thể hiện qua việc định lượng các chức năng nghiệp vụ của hệ

thống được phân phối cho người dùng Phương pháp này được đưa ra bởi tác giả Allan Albretch thuộc tổ chức IBM, năm 1979

1.3.1.2 Nội dung của phương pháp

3 bước để tiến hành đánh giá kích cỡ của một hệ thống được xây dựng bằng phương pháp phân tích Điểm Chức năng:

- 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

- Tính toán cuối cùng

Tính toán cụ thể:

Bước 1: Xác định kích cỡ xử lý thông tin thô của hệ thống

Kích cỡ xử lý thông được tính bởi phép xác định các thành phần hệ thống như được thấy bởi người dùng cuối, và phân loại chúng thành 5 loại:

- Các đầu vào ngoại vi

- Các đầu ra ngoại vi

- Các truy vấn ngoại vi

- Các file logic nội bộ

- Các giao diện ngoại vi

Mỗi thành phần thuộc mỗi loại lại được đánh giá độ phức tạp là “đơn giản”,

“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

ni, j * Wi, j

trong đó:

UFPs : tổng Điểm Chức năng chưa được điều chỉnh

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

j : nhận các giá trị từ 1 đến 3, đại diện cho 3 mức độ phức tạp

ni, j : là số lượng thành phần thuộc loại i có độ phức tạp j

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

Kích cỡ xử lý thông tin thô (UFPs) sẽ được điều chỉnh bởi các yếu tố kĩ thuật, cái mà ảnh hưởng lên quá trình phát triển và thi hành hệ thống

Mã y ếu tố Đặc trưng yếu tố M ức độ ảnh hưởng

F2 Xử lý dữ liệu phân tán …

20

Mã y ếu tố Đặc trưng yếu tố M ức độ ảnh hưởng

F4 Cấu hình sử dụng nặng …

F6 Vào dữ liệu trực tuyến …

F7 Hiệu quả người dùng cuối …

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

không xu ất hiện, không ảnh hưởng = 0 ảnh hưởng không đáng kể = 1

ảnh hưởng vừa phải = 2 ảnh hưởng trung bình = 3 ảnh hưởng đáng kể = 4 ảnh hưởng mạnh, khắp nơi = 5

Có 14 yếu tố chuẩn, được tác giả Albretch đề xuất như là 14 “Đặc trưng ứng

dụng tổng quát”, sẽ được tính toán để đưa vào một con số được gọi là Y ếu tố Độ

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

phạm vi ảnh hưởng của mỗi yếu tố được xếp loại và cho điểm từ 0 (không ảnh 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:

TCF = C 1 + C 2 ∑

= 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:

TCF = C 1 + C 2 * DI

Bước 3: Tính toán cuối cùng

Kích cỡ xử lý thông tin của một hệ thống theo số lượng Điểm Chức năng (FPs) được tính theo công thức:

FPs = UFPs * TCF

Trong đó:

FPs : số điểm chức năng của hệ thống

UFPs : số điểm chứ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

1.3.1.3 Đánh giá phương pháp

a) Ưu điểm

FPA đếm số chức năng dựa vào cách nhìn từ bên ngoài vào hệ thống của 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ể

Phép đo có thể được xác định sớm trong vòng đời phát triển của dự án, chỉ

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

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

b) Nhược điểm

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

phải đưa ra nhiều đánh giá chủ quan Cụ thể, mọi đầu vào, đầu ra, truy vấn, file và các giao diện phải được đánh giá thành đơn giản, trung bình hay phức tạp và các

nhất là 0 và giá trị lớn nhất là 5 Các yếu tố khác nhau thì tầm ảnh hưởng cũng khác 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ệ

thống nhưng mức độ quan trọng của chúng là khác nhau Do đó, nên cho mỗi yếu tố

một trọng số ảnh hưởng, sau đó điểm của yếu tố được tính bằng cách nhân điểm tỉ

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

Ngoài ra, trong xem xét điều chỉnh số lượng Điểm Chức năng của hệ 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

được xem xét trong phương pháp FPA Theo ([9] Symons, 1988), điều này được tác

giả của phương pháp lý giải là để cách ly việc xử lý bên trong với môi trường bên 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ột số lượng người đến, năng

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

FPA có lẽ là một phương pháp rất tốt ở thời điểm được đưa ra nhưng cho đến bây giờ thì có nhiều điểm không phù hợp

Các hệ thống bây giờ không chỉ phụ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ứ không phải xây dựng lại từ đầu (theo quan điểm Hướng đối tượng) Các mô – đun

thừa kế từ mô – đun khác Số chức năng của hai mô – đun khác nhau có thể có nhiều chức năng dùng chung từ một mô – đun khác Việc đếm số chức năng dùng 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ố lượng các thực thể hoặc số lượng các bảng (loại thực thể) chứ không phải là số lượng các file logic trong thao tác của hệ quản

trị cơ sở dữ liệu

Một hạn chế nữa của FPA là mặc dù bình thường FPA làm việc cho các ứng

dụng nghiệp vụ, nhưng có thể nó không có hiệu lực cho các loại ứng dụng khác, như là khoa học hay công nghệ Điều này phát sinh từ chính khả năng có giới hạn

của nó để giải quyết độ phức tạp nội hàm Độ phức tạp nội hàm trong các ứng dụng nghiệp vụ phát sinh chủ yếu từ các tiến trình xác minh và từ các tương tác với dữ

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 thuật toán tính toán nội hàm phức tạp, thì FPA không phải là một cách hợp lý để

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

1.3.2 Mô hình đánh giá giá cấu thành (COCOMO – Constructive Cost Model)

1.3.2.1 Tóm lược

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

của phần mềm dựa trên đánh giá kích cỡ của chương trình được phân phối cho ngườ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

1.3.2.2 Nội dung mô hình

Có ba mức độ của mô hình: Cơ sở, Trung cấp và Nâng cao

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

Mô hình COCOMO cơ sở tính toán giá (nỗ lực và thời gian) phát triển phần

mềm như là một hàm của kích cỡ chương trình Kích cỡ của chương trình được biểu

diễn theo đơn vị nghìn dòng lệnh (KLOC – kilo line of code)

Trước tiên, COCOMO phân biệt 3 phương thức phát triển dự án:

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

những đội nhỏ trong môi trường quen thuộc với những yêu cầu không quá

24

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

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à độ

phức tạp) được phát triển bởi đội phát triển có trình độ khác nhau với những ràng buộc mạnh mẽ hơn so với phương thức organic, tuy nhiên vẫn có một

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

- embedded: cho những dự án với những ràng buộc chặt chẽ về phần cứng,

phần mềm và thi hành, … Dự án phải phát triển từ đầu và không thể nhận được sự trợ giúp từ những số liệu của các dự án khác

Từ đó các phương trình của mô hình COCOMO cơ sở là:

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:

Semi - detached 3.0 1.12 2.5 0.35

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

b Mô hình COCOMO trung c ấp (intermediate COCOMO)

- Biến động môi trường máy ảo

- Thời gian xoay vòng yêu cầu

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

- Khả năng phân tích

- Khả năng kĩ nghệ phần mềm

- Kinh nghiệm ứng dụng

- Kinh nghiệm máy ảo

- 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

- Ứng dụng của các phương pháp kĩ nghệ phần mềm

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

Mỗi Yếu tố trong số 15 yếu tố trên được đánh tỉ lệ theo một thang có 6 mức

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

bảng dưới Tích của tất cả các thừa số nỗ lực được gọi là Yếu tố Điều chỉnh Nỗ lực (EAF – Effort Adjust Factor) Giá trị của EAF dao động từ 0.9 tới 1.4

Công thức:

F EAF

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

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

Biến động môi trường máy ảo 0.87 1.00 1.15 1.30

Thời gian xoay vòng yêu cầu 0.87 1.00 1.07 1.15

Nhân l ực

Khả năng phân tích 1.46 1.19 1.00 0.86 0.71

Khả năng kĩ nghệ phần mềm 1.29 1.13 1.00 0.91 0.82

Kinh nghiệm ứng dụng 1.42 1.17 1.00 0.86 0.70

Kinh nghiệm máy ảo 1.21 1.10 1.00 0.90

Kinh nghiệm ngôn ngữ lập trình 1.14 1.07 1.00 0.95

D ự án

Việc dùng các công cụ phần mềm 1.24 1.10 1.00 0.91 0.82

Ứng dụng của các phương pháp kĩ

nghệ phần mềm 1.24 1.10 1.00 0.91 0.83

Lịch trình phát triển được yêu cầu 1.23 1.08 1.00 1.04 1.10

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

27

Công thức COCOMO cơ sở bây giờ chuyển thành dạng:

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

trong đó:

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

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

Semi - detached 3.0 1.12

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 trung cấp với một đánh giá ảnh hưởng của thuộc tính điều chỉnh giá vào từng pha (phân tích, thiết kế,…) trong tiến trình kĩ nghệ phần mềm

COCOMO nâng cao cũng được gọi là Ada COCOMO

1.3.2.3 Đánh giá mô hình

a) Ưu điểm

Mô hình có thuật toán rất rõ ràng, và chúng ta có thể xem cách nó hoạt động

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

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

hiện dự án, một bổ sung so với FPA Các Yếu tố được cho điểm chi tiết, điều này giúp ích tốt cho việc đánh giá mức độ ảnh hưởng của mỗi yếu tố để điều chỉnh giá

của dự án

b) Nhược điểm

Nhược điểm lớn nhất của COCOMO là việc đánh giá số dòng lệnh của 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ẻ không khả thi, khó có thể đưa ra một đánh giá sớm và đáng tin cậy Điều này phụ thuộc công nghệ được dùng để triển khai Việc lựa chọn ngôn ngữ lập trình nào ảnh

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

diện Đánh giá số dòng lệnh để ước lượng giá theo mô hình COCOMO trong trường

hợp này không còn đúng nữa vỡ cỏc lệnh được sinh ra tự động chứ không phải do 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ột số lượ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ỗ lực và thời gian phát triển) cụ thể, giá sản phẩm này có thể được điều

chỉnh bằng các yếu tố điề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ột số lượ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

đó bởi các ngôn ngữ khác nhau là khác nhau Hơn nữa, ngay cả trong cùng 1 ngôn

ngữ thì các đoạn mã khác nhau mà có cùng số lượng dòng cũng chứa lượng tri thức khác nhau, tức là nỗ lực phát triển khác nhau

Việc phân biệt 3 phương thức phát triển dự án có lẽ là hợp lý ở thời điểm mà COCOMO được đưa ra nhưng hiện nay, cách phân biệt như vậy là không rõ ràng và

dễ gây nhầm lẫn Cụ thể, có thể có những dự án nhỏ, có lẽ thuộc chế độ organic, 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 phương pháp đánh giá công sức dự án theo Use Case (Use Case Points)

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 người dùng mà nó dự định sẽ trợ giúp – thay vì là một tập hợp khó hiểu và rối rắm 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 không bao giờ hiểu được và không thể làm việc cùng

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

hệ thống mới sẽ phải làm gì hoặc một hệ thống đang tồn tại làm gì Một mô hình 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

3 Mô tả 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:

- Phương pháp điểm chức năng nghiệp vụ (FPA)

- Phương pháp đánh giá giá cấu thành phần mềm (COCOMO)

- Phương pháp điểm chức năng sử dụng (UCP)

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 sức phần mềm theo mô hình Use Case

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

thông đã có hướng dẫn số 2589/BTTTT-ƯDCNTT ngày 24/8/2011 về xác định xác

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 mềm Hướng đối tượng Sau đó vài năm Ngôn ngữ Mô hình hóa Thống nhất (UML)

đã 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 hướng đối tượng UML đã được đưa vào Quy trình thống nhất (RUP – Rational 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

Như được đặc tả trong ([4] Jacobson, 2005), các Use Case mô tả những cái

mà tác nhân muốn hệ thống thực hiện Các Use Case bao gồm các mục tiêu chiến 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 các tác nhân và các kịch bản của một Use Case

Năm 1993, Gustav Karner đã sáng tạo ra kĩ thuật đánh giá công sức dự án dựa trên phương pháp điểm Use Case (UCP – Use Case Point), tài liệu ([5] Karner, 1993), dựa theo phương pháp phân tích điểm chức năng của Abretch Use Case 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 động (activity diagram) Mặc dầu vậy, một Use Case cần phải được mô tả sao cho

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 đó :

- Hệ thống được thể hiện qua hình chữ nhật với tên hệ thống ở bên trên

- Tác nhân được thể hiện qua kí hiệu hình nhân

- Use Case được thể hiện qua hình ellipse

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ệ thống mà ta muốn phát triển cần phải được định nghĩa rõ ràng Một hệ thống không 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õ

Ra tình

huống

Xây dựng bài tập

Người tập

Chỉ huy

luyện tập

Hệ thống mô phỏng điều khiển tàu biển

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

Đ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ả Use Case Phương thức cụ thể của bản danh mục này có thể rất khác nhau; nó có thể

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 thật sự và cụ thể của hệ thống Nếu một người nào đó muốn mua hợp đồng bảo