Tài liệu Báo cáo Nghiên cứu ước lượng dự án: TRƯỜNG ………………….
KHOA……………………….
---------
Báo cáo tốt nghiệp
Đề tài:
NGHIÊN CỨU ƯỚC LƯỢNG DỰ ÁN
LỜI CÁM ƠN
Em xin chân thành cám ơn tất cả các thầy cô trong trường đã truyền đạt nhiều kiến
thức bổ ích cho em trong những năm học tập tại trường.
Đặc biệt, em xin cám ơn thầy giáo PGS. TS. Nguyễn Văn Vỵ, người hướng dẫn trực
tiếp và giúp em hoàn thành tốt khóa luận này.
TÓM TẮT NỘI DUNG
Khóa luận nghiên cứu về phương pháp ước lượng dự án phần mềm.
Bố cục có 2 phần:
Phần 1 nêu ra những nguyên tắc cơ bản trong ước lượng dự án phần mềm, và giới
thiệu 2 phương pháp ước lượng nổi tiếng là phương pháp Phân tích Điểm Chức năng
(FPA – Function Point Analysis) và Mô hình giá cấu thành (COCOCO – Constructive
Cost Model) cùng những đánh giá về 2 phương pháp trong bối cảnh phát triển phần
mềm hiện nay.
Phần 2 có nội dung giới thiệu và đánh giá phương pháp ước lượng dự án phần mềm
dựa trên Điểm Ca Sử dụng (UCP – Use Case Point), là phương pháp rất phù hợp c...
80 trang |
Chia sẻ: haohao | Lượt xem: 1620 | Lượt tải: 0
Bạn đang xem trước 20 trang mẫu tài liệu Báo cáo Nghiên cứu ước lượng dự án, để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
TRƯỜNG ………………….
KHOA……………………….
---------
Báo cáo tốt nghiệp
Đề tài:
NGHIÊN CỨU ƯỚC LƯỢNG DỰ ÁN
LỜI CÁM ƠN
Em xin chân thành cám ơn tất cả các thầy cô trong trường đã truyền đạt nhiều kiến
thức bổ ích cho em trong những năm học tập tại trường.
Đặc biệt, em xin cám ơn thầy giáo PGS. TS. Nguyễn Văn Vỵ, người hướng dẫn trực
tiếp và giúp em hoàn thành tốt khóa luận này.
TÓM TẮT NỘI DUNG
Khóa luận nghiên cứu về phương pháp ước lượng dự án phần mềm.
Bố cục có 2 phần:
Phần 1 nêu ra những nguyên tắc cơ bản trong ước lượng dự án phần mềm, và giới
thiệu 2 phương pháp ước lượng nổi tiếng là phương pháp Phân tích Điểm Chức năng
(FPA – Function Point Analysis) và Mô hình giá cấu thành (COCOCO – Constructive
Cost Model) cùng những đánh giá về 2 phương pháp trong bối cảnh phát triển phần
mềm hiện nay.
Phần 2 có nội dung giới thiệu và đánh giá phương pháp ước lượng dự án phần mềm
dựa trên Điểm Ca Sử dụng (UCP – Use Case Point), là phương pháp rất phù hợp cho
những dự án được kĩ nghệ theo phương pháp Hướng Đối tượng, khắc phục được nhiều
nhược điểm của các phương pháp truyền thống. Trong phần này, sẽ tiến hành xây
dựng một chương trình tính toán hỗ trợ cho việc ước lượng theo phương pháp Điểm
Ca Sử dụng. Chương trình được kĩ nghệ theo phương pháp Hướng Đối tượng và tài
liệu phân tích của nó lại được dùng cho việc đánh giá thực tế áp dụng phương pháp
Điểm Ca Sử dụng.
MỤC LỤC
LỜI CÁM ƠN
TÓM TẮT NỘI DUNG
MỤC LỤC
DANH SÁCH CÁC TỪ VIẾT TẮT
DANH SÁCH CÁC BẢNG
DANH SÁCH CÁC HÌNH
PHẦN 1 TỔNG QUAN VỀ PHƯƠNG PHÁP ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM
CHƯƠNG 1 NHỮNG NGUYÊN TẮC CƠ BẢN TRONG ƯỚC LƯỢNG DỰ ÁN PHẦN
MỀM
1.1 Tổng quan ước lượng dự án phần mềm ........................................................................... 2
1.2 Bốn bước cơ bản trong ước lượng dự án phần mềm ........................................................ 4
1.2.1 Ước lượng kích cỡ................................................................................................................... 4
1.2.2 Ước lượng nỗ lực .................................................................................................................... 5
1.2.2.1 Vấn đề ước lượng nỗ lực trực tiếp.................................................................................... 7
1.2.3 Ước lượng lịch trình ................................................................................................................ 7
1.2.4 Ước lượng chi phí.................................................................................................................... 8
CHƯƠNG 2 NGHIÊN CỨU PHƯƠNG PHÁP ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM
TRUYỀN THỐNG
2.1 Phương pháp Phân tích Điểm Chức năng (FPA – Function Points Analysis)..................11
2.1.1 Tóm lược ...............................................................................................................................11
2.1.2 Nội dung của phương pháp .....................................................................................................11
2.1.3 Đánh giá phương pháp............................................................................................................14
2.2 Mô hình ước lượng giá cấu thành (COCOMO – Constructive Cost Model) ....................16
2.2.1 Tóm lược ...............................................................................................................................16
2.2.2 Nội dung mô hình...................................................................................................................16
2.2.2.1 Mô hình COCOMO cơ sở (basic COCOMO)..................................................................16
2.2.2.2 Mô hình COCOMO trung cấp (intermediate COCOMO) ................................................17
2.2.2.3 Mô hình COCOMO nâng cao (advanded COCOMO) .....................................................20
2.2.3 Đánh giá mô hình ...................................................................................................................20
2.3 Kết hợp Phương pháp Phân tích Điểm Chức năng với Mô hình Giá Cấu thành (FPA và
COCOMO)................................................................................................................................21
2.3.1 Nội dung kết hợp....................................................................................................................21
2.3.2 Đánh giá phép kết hợp............................................................................................................22
PHẦN 2 ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM THEO ĐIỂM CA SỬ DỤNG
CHƯƠNG 3 GIỚI THIỆU PHƯƠNG PHÁP ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM THEO
ĐIỂM CA SỬ DỤNG (USE CASE POINT)
3.1 Tóm lược .......................................................................................................................25
3.2 Nội dung phương pháp...................................................................................................26
3.2.1 Tính số Điểm Ca Sử dụng (UCPs) ..........................................................................................26
3.2.1.1 Tính số Điểm Ca Sử dụng Chưa được điều chỉnh (UUCPs – Unadjusted Use Case Points)
27
3.2.1.2 Tính Yếu tố Độ phức tạp Kĩ thuật...................................................................................31
3.2.1.3 Tính Yếu tố Độ phức tạp Môi trường (ECF – Environmental Complexity Factor)............33
3.2.1.4 Tính số Điểm Ca Sử dụng ..............................................................................................36
3.2.2 Ước lượng nỗ lực từ số Điểm Ca Sử dụng...............................................................................36
CHƯƠNG 4 XÂY DỰNG CHƯƠNG TRÌNH TÍNH TOÁN HỖ TRỢ ƯỚC LƯỢNG UCP
ESTIMATOR
4.1 Phát biểu bài toán..........................................................................................................38
4.2 Phân tích bài toán..........................................................................................................38
4.2.1 Phân tích tổng thể...................................................................................................................38
4.2.2 Phân tích cụ thể chức năng......................................................................................................39
4.3 Đặc tả chương trình.......................................................................................................39
4.3.1 Biểu đồ ca sử dụng của chương trình.......................................................................................39
4.3.2 Các biểu đồ hoạt động ............................................................................................................40
4.3.2.1 Biểu đồ hoạt động của ca sử dụng số 1 ...........................................................................40
4.3.2.2 Biểu đồ hoạt động của ca sử dụng số 2 ...........................................................................41
4.4 Thiết kế logic hoạt động cho chương trình .....................................................................42
4.4.1 Xác định các lớp phân tích......................................................................................................42
4.4.2 Các biểu đồ cộng tác...............................................................................................................42
4.4.2.1 Biểu đồ cộng tác cho ca sử dụng số 1..............................................................................42
4.4.2.2 Biểu đồ cộng tác cho ca sử dụng số 2..............................................................................43
4.4.3 Các biểu đồ tuần tự.................................................................................................................44
4.4.3.1 Biểu đồ tuần tự cho ca sử dụng số 1................................................................................44
4.4.3.2 Biểu đồ tuần tự cho ca sử dụng số 2................................................................................45
4.5 Thiết kế cơ sở dữ liệu.....................................................................................................45
4.5.1 Phân tích bài toán để xây dựng cơ sở dữ liệu...........................................................................45
4.5.2 Xây dựng biểu dồ thực thể - liên kết (E-R) ..............................................................................46
4.5.3 Xây dựng lược đồ quan hệ ......................................................................................................49
CHƯƠNG 5 ÁP DỤNG VÀ ĐÁNH GIÁ PHƯƠNG PHÁP ƯỚC LƯỢNG ĐIỂM CA SỬ
DỤNG
5.1 Áp dụng thực tế..............................................................................................................51
5.1.1 Bài toán số 1 – Dự án xây dựng mô–đun cho máy rút tiền ATM..............................................51
5.1.1.1 Miêu tả dự án.................................................................................................................51
5.1.1.2 Ước lượng kích cỡ .........................................................................................................51
tính số Điểm Ca Sử dụng ................................................................................................................51
5.1.1.3 Ước lượng nỗ lực...........................................................................................................53
5.1.2 Bài toán số 2 – Dự án xây dựng chương trình UCP Estimator..................................................53
5.1.2.1 Miêu tả dự án.................................................................................................................53
5.1.2.2 Ước lượng kích cỡ .........................................................................................................54
tính số Điểm Ca Sử dụng ................................................................................................................54
5.1.2.3 Ước lượng nỗ lực...........................................................................................................59
5.2 Đánh giá phương pháp ..................................................................................................59
5.2.1 Đánh giá quy trình tính toán....................................................................................................59
5.2.1.1 So sánh UCP với FPA....................................................................................................59
5.2.1.2 So sánh UCP với COCOMO ..........................................................................................60
5.2.2 Đánh giá trên thực tế ..............................................................................................................61
5.2.3 Kết luận .................................................................................................................................62
5.3 Đề xuất hướng phát triển ...............................................................................................62
5.3.1 Phát triển lý thuyết chương trình.............................................................................................62
5.3.2 Phát triển chương trình tính toán UCP Estimator .....................................................................63
PHỤ LỤC A. DỰ ÁN XÂY DỰNG MÔ – ĐUN ATM ...................................................... 64
TÀI LIỆU THAM KHẢO................................................................................................. 69
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
ECF : Environmental Complexity Factor – Yếu tố độ phức tạp môi trường
ER : Effort Rating – tỉ lệ nỗ lực
FP : Function Point – Điểm chức năng
FPA : Function Point Analysis – Phân tích điểm chức năng
FPs : Function Points – số Điểm chức năng
KLOC : Kilo Line Of Code – số nghìn dòng lệnh
LOC : Line Of Code – số dòng lệnh
RUP : Rational Unified Process – Tiến trình thống nhất
TCF : Technical Complexity Factor – Yếu tố độ phức tạp kĩ thuật
UCP : Use Case Point – Điểm ca sử dụng
UCPs : Use Case Points – số Điểm ca sử dụng
UFP : Unadjusted Function Point – Điểm Chức năng chưa được điều chỉnh
UFPs : Unadjusted Function Points – số Điểm Chức năng chưa được điều
chỉnh
UML : Unified Modelling Language – ngôn ngữ mô hình hóa thống nhất
UUCP : Unadjusted Use Case Point – Điểm ca 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
WAs : Weighted Actors – số lượng Tác nhân sau khi đánh trọng số
WUCs : Weighted Use Cases – số lượng Ca sử dụng sau khi đánh trọng số
DANH SÁCH CÁC BẢNG
Chương 1:
Chương 2:
Bảng 2-1. Tính UFPs – kích cỡ xử lý thông tin thô – trong FPA
Bảng 2-2. Mười bốn Yếu tố kĩ thuật trong FPA
Bảng 2-3. Phân loại chế độ phát triển sản phẩm trong COCOMO cơ sở
Bảng 2-4. Các Yếu tố điều chỉnh trong COCOMO trung cấp
Bảng 2-5. Phân loại chế độ phát triển trong COCOMO trung cấp
Bảng 2-6. Đề xuất tỉ lệ LOC/FP cho phép kết hợp FPA và COCOMO.
Chương 3:
Bảng 3-1. Phân loại và đánh trọng số ca sử dụng trong UCP
Bảng 3-2. Ví dụ đếm số ca sử dụng sau khi đánh trọng số
Bảng 3-3. Phân loại và đánh trọng số tác nhân trong UCP
Bảng 3-4. Ví dụ đếm số tác nhân sau khi đánh trọng số
Bảng 3-5. Trọng số của 13 yếu tố kĩ thuật trong UCP
Bảng 3-6. Ví dụ tính Yếu tố Độ phức tạp Kĩ thuật trong UCP
Bảng 3-7. Trọng số của 8 yếu tố môi trường trong UCP
Bảng 3-8. Ví dụ tính Yếu tố Độ phức tạp Môi trường trong UCP
Chương 4:
Bảng 4-3. Kịch bản ca sử dụng “Thực hiện ước lượng mới” – UCP Estimator
Bảng 4-4. Kịch bản ca sử dụng “Tìm kiếm ước lượng lịch sử” – UCP Estimator
Chương 5:
Bảng 5-5. Đếm WUCs - dự án ATM
Bảng 5-2. Đếm WAs – dự án ATM
Bảng 5-3. Đếm WUCs - dự án UCP Estimator
Bảng 5-4. Đếm WAs - dự án UCP Estimator
Bảng 5-5. Cho điểm các Yếu tố kĩ thuật - dự án UCP Estimator
Bảng 5-6. Cho điểm các Yếu tố môi trường - dự án UCP Estimator
DANH SÁCH CÁC HÌNH
Chương 1:
Hình 1-1. Đồ thị hội tụ ước lượng.
Hình 1-2. Tiến trình cơ sở Ước lượng dự án
Chương 2:
Chương 3:
Chương 4:
Hình 4-1. Biểu đồ ca sử dụng tổng thể - UCP Estimator
Hình 4-2. Biểu đồ hoạt động của ca sử dụng "Thực hiện Ước lượng mới" - UCP
Estimator
Hình 4-3. Biểu đồ hoạt động của ca sử dụng "Tìm kiếm Ước lược lịch sử" - UCP
Estimator
Hình 4-4. Biểu đồ cộng tác cho ca sử dụng "Thực hiện ước lượng mới" - UCP
Estimator
Hình 4-5. Biểu đồ cộng tác cho ca sử dụng "Tìm kiếm ước lượng lịch sử" - UCP
Estimator
Hình 4-6. Biểu đồ tuần tự cho ca sử dụng "Thực hiện ước lượng mới" - UCP
Estimator
Hình 4-7. Biểu đồ tuần tự cho ca sử dụng "Tìm kiếm ước lượng lịch sử" - UCP
Estimator
Hình 4-8. Biểu đồ thực thể-mối quan hệ - UPC Estimator
Chương 5:
1
PHẦN 1
TỔNG QUAN VỀ PHƯƠNG PHÁP
ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM
Chương 1 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
2
Chương 1
NHỮNG NGUYÊN TẮC CƠ BẢN TRONG
ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM
1.1 Tổng quan ước lượng dự án phần mềm
Ước lượng dự án 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. Ước lượng 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ả: Lập kế hoạch và điều khiển dự án có hiệu
quả là không thể nếu không có một ước lượng đầy đủ và đáng tin cậy. Nhiều tổ chức
phải chịu các tác động tài chính lên công việc của họ, 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 do các các ước lượng xấu.
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 lượng dự án tốt và cũng không sử dụng các ước lượng hợp lý .
Hình 1-1 , tham khảo từ tài liệu ([6] McConnell, 1996) thể hiện độ hội tụ của ước
lượng trong vòng đời phát triển dự án của các dự án thực tế, ước lượng 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 ước lượng đá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ả, dó đó chúng ta
cần tập trung nhiều nỗ lực để giải quyết tình hình
Ước lượng thiếu 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à (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 ước lượng, thì ước lượng thừ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
Chương 1
3
Management?, 2010):
“Work expands so 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.
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
Xác định
sản phẩm
ban đầu
Giá dự án
(nỗ lực và kích cỡ) Lịch trình dự án
1.0 x
1.25 x
1.5 x
2 x
4 x
0.25 x
0.5 x
0.67 x
0.8 x
1.05
1.15 x
1.25 x
1.6 x
0.6 x
0.8 x
0.85 x
0.9 x
1.0 x
Hình 1-3. Đồ thị hội tụ ước lượng. Độ chính xác của ước lượng chỉ được cải tiến chính trong quá trình phát
triển. Nguồn tham khảo: ([6] McConnell. 1996)
Chương 1
4
1.2 Bốn bước cơ bản trong ước lượng dự án phần
mềm
Bốn bước chính trong ước lượng dự án phần mềm là:
1) ước lượng 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 ước lượng của 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 ước lượng 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ố ca 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) ước lượng 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) ước lượng 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 ước lượng 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) ước lượng 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ô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 Ước lượng kích cỡ
Một ước lượng chính xác của kích cỡ của phần mềm được xây dựng là bước đầu tiên
cho một ước lượng có hiệu quả. Các tài nguyên thông tin về phạm vi 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 – ví dụ, một đặc tả các yêu cầu của khách hàng hoặc yêu cầu cho đề xuất, một đặc
tả hệ thống. 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 ước lượng cũng không nên chốt cứng. Trong mọi trường hợp,
Chương 1
5
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 ước lượng cho
mọi khía cạnh và phải thực hiện lại ước lượng 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 ước lượng 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ể ước lượng 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ể ước lượng 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. Ước lượng 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 ước lượng 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 ca 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 ước lượng 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 ước lượng 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.
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 Ước lượng nỗ lực
Một khi chúng ta có một ước lượng của kích cỡ của sản phẩm, chúng ta có thể tính
toán ước lượng 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
Chương 1
6
đị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 ¼ 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ể. Ước
lượng nỗ lực dự án yêu cầu ta xác định và ước lượng, và 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 ước lượng.
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 lượng 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 ước lượng đượ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, rằng (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), và rằng (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 ra 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 ước lượng kích cỡ thành một ước lượng 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 ước lượng nỗ lực gần đúng hữu ích.
Chương 1
7
1.2.2.1 Vấn đề ước lượng 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 ước lượng kích cỡ sản phẩm. Không phải là lạ khi nhìn thấy nỗ lực được
ước lượng trực tiếp từ một mô tả của sản phẩm/dự án, bỏ qua hoàn toàn ước lượng
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
ước lượng 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 lượng ban đầu không theo các mục đích
của chúng ta, việc làm lại ước lượng để xem điều gì xảy ra với những đội phát triển
khác đòi hỏi ước lượng phải được tính lại từ đầu. Bằng cách ước lượng kích cỡ trước
chúng ta dễ dàng làm lại nhanh ước lượng 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.
1.2.3 Ước lượng lịch trình
Bước thứ ba trong ước lượng một dự án phát triển phần mềm là xác định lịch trình dự
án từ ước lượng nỗ lực. Điều này thường đòi hỏi ước lượng 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 (cái này 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 ước lượng 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 ra đã ước lượng 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.
Ước lượng 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
Chương 1
8
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 ước lượng lịch trình, để ý rằng công
việc ước lượng 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ũ 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 ước lượng theo biểu thức tính lịch trình ở trên, ta ước lượng 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 ước lượng 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 ước lượng 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ố ca làm việc mỗi ngày, số giờ làm việc hiệu quả trong mỗi ca
- 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 ước lượng 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 Ước lượng chi phí
Có nhiều yếu tố để quan tâm khi ước lượng 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, …
Chương 1
9
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 ước
lượng nỗ lực của dự án (theo giờ) với lương nhân công tính trung 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, quản lý dự án, người lập tài
liệu, cộng tác viên, …). Chúng ra sẽ phải xác định xem 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.
Qua việc nghiên cứu 4 bước trong phép ước lượng như trên, đề xuất một tiến trình cơ
sở cho việc ước lượng như được mô tả trong sơ đồ ở Hình 2-2:
Chương 1
10
Kích cỡ, nỗ
lực,chi phí
thực tế, …
Thu thập các yêu
cầu ban đầu
Ước lượng nỗ lực
Ước lượng kích cỡ
sản phẩm
Đưa ra lịch trình
Ước lượng chi phí
Phê duyệt ước
lượng
Phát triển sản phẩm Phân tích tiến trình
ước lượng
Dữ liệu giá hiện
thời
Ước lượng
được phê duyệt
Các tài nguyên
sẵn có
Dữ liệu dự án
lịch sử
Hình 1-4. Tiến trình cơ sở Ước lượng dự án. Nguồn tham khảo: ([3] Hewson, 2007).
Chương 2 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
11
Chương 2
NGHIÊN CỨU PHƯƠNG PHÁP ƯỚC
LƯỢNG DỰ ÁN PHẦN MỀM
TRUYỀN THỐNG
Đã có một số phương pháp được đề xuất cho việc ước lượng để 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 Chức năng
FPA và Mô hình Giá Cấu thành COCOMO. Hai phương pháp này còn có thể được kết
hợp cùng nhau để ước lượng lượng tài nguyên cần thiết trong dự án. Trong chương
này em sẽ nêu nội dung thuật toán và đánh giá phân tích 2 phương pháp này cũng như
là phép kết hợp 2 phương pháp.
2.1 Phương pháp Phân tích Điểm Chức năng (FPA –
Function Points Analysis)
2.1.1 Tóm lược
Phân tích Điểm Chức năng (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.
2.1.2 Nội dung của phương pháp
3 bước để tiến hành ước lượng 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ể:
Chương 2
12
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 tố khác.
Sau đó đánh trọng số (cho điểm) đến từng độ phức tạp của mỗi loại thành phần.
Cộng điểm tổng cộng để xác định kích cỡ xử lý thông tin thô, gọi là tổng Điểm Chức
năng Chưa được điều chỉnh (UFPs – Unadjusted Function Points).
UFPs =
ji,
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
Wi, j : là trọng số của loại i có độ phức tạp j
Độ phức tạp Loại chức năng
Đơn giản Trung bình Phức tạp Tổng
Đầu vào ngoại vi * 3 = * 4 = * 6 =
Đầu ra ngoại vi * 4 = * 5 = * 7 =
File logic nội bộ * 7 = * 10 = * 15 =
Giao diện ngoại vi * 5 = * 7 = * 10 =
Truy vấn ngoại vi * 3 = * 4 = * 6 =
UFPs =
Bảng 2-6. Tính UFPs – kích cỡ xử lý thông tin thô – trong FPA
Chương 2
13
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
F1 Truyền thông dữ liệu …
F2 Xử lý dữ liệu phân tán …
F3 Hiệu năng …
F4 Cấu hình sử dụng nặng …
F5 Tỉ lệ giao dịch …
F6 Vào dữ liệu trực tuyến …
F7 Hiệu quả người dùng cuối …
F8 Cập nhật trực tuyến …
F9 Xử lý phức tạp …
F10 Khả năng dùng lại …
F11 Cài đặt dễ dàng …
F12 Thi hành dễ dàng …
F13 Đa địa điểm (tính chất phân tán) …
F14 Thay đổi dễ dàng …
Mức độ ảnh hưởng tổng cộng DI =
Bảng 2-7. 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 = C1 + C2
14
1i
Fi
trong đó:
Chương 2
14
TCF là Yếu tố Độ phức tạp Kĩ thuật
C1 = 0.65
C2 = 0.01
Fi là mức độ ảnh hưởng của yếu tố kĩ thuật thứ i, có giá trị từ 0 đến 5
Để ý rằng đại lượng DI =
14
1i
Fi 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 = C1 + C2 * 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
2.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 ước lượng 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 yếu tố kĩ thuật cũng
được đánh giá bởi cảm nhận của con người.Tuy vậy thì những chuyên gia cũng có thể
đưa ra những đánh giá kinh nghiệm có độ chính xác cao.
Chương 2
15
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ỏ 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ố 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
Chương 2
16
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ế.
2.2 Mô hình ước lượng giá cấu thành (COCOMO –
Constructive Cost Model)
2.2.1 Tóm lược
Mô hình COCOMO là mô hình ước lượng 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.
2.2.2 Nội dung mô hình
Tác giả đã đề xuất ba mức độ của mô hình: Cơ sở, Trung cấp và Nâng cao.
2.2.2.1 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á 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
Chương 2
17
- 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 = ab * (KLOC)bb
T = cb * db
P = E / T
trong đó:
KLOC : là số nghìn dòng lệnh của dự án
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,
ab, bb, cb, db : 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:
Phương thức a b c d
Organic 2.4 1.05 2.5 0.38
Semi - detached 3.0 1.12 2.5 0.35
embedded 3.6 1.2 2.5 0.32
Bảng 2-3. Phân loại chế độ phát triển sản phẩm trong COCOMO cơ sở
2.2.2.2 Mô hình COCOMO trung cấp (intermediate COCOMO)
Mô hình COCOMO trung cấp là một sự mở rộng của mô hình cơ sở để xem xét thêm
một tập các Yếu tố điều chỉnh giá mà được nhóm vào 4 loại chính, mỗi loại lại được
phân chia thành các loại con:
Nhóm 1:Các thuộc tính sản phẩm
- Độ ổn định phầm mềm yêu cầu
- Kích cỡ của cơ sở dữ liệu ứng dụng
- Độ phức tạp của sản phẩm
Nhóm 2:Các thuộc tính phần cứng
Chương 2
18
- Các ràng buộc hiệu năng thời gian thực
- Các ràng buộc bộ nhớ chính
- 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:
15
1i
iFEAF
trong đó:
EAF : Yếu tố Điều chỉnh Nỗ lực
Fi : Yếu tố thứ i, có giá trị như Bảng 2-4
Chương 2
19
Tỉ lệ
Các thuộc tính Rất thấp Thấp Bình
thường
Cao Rất
cao
Đặc biệt
cao
Sản phẩm
Độ ổn định yêu cầu 0.75 0.88 1.00 1.15 1.40
Kích cỡ của cơ sở dữ liệu
ứng dụng
0.94 1.00 1.08 1.16
Độ phức tạp sản phẩm 0.70 0.85 1.00 1.15 1.30 1.65
Phần cứng
Ràng buộc hiệu năng thời
gian thực
1.00 1.11 1.30 1.66
Ràng buộc bộ nhớ chính 1.00 1.06 1.21 1.56
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 2-4. Các Yếu tố điều chỉnh trong COCOMO trung cấp
Chương 2
20
Công thức COCOMO cơ sở bây giờ chuyển thành dạng:
E = ai * (KLOC)bi * EAF
trong đó:
EAF : là yếu tố điều chỉnh nỗ lực được tính như ở trên
ai và bi : là các hệ số được đưa ra như bảng sau:
Phương thức a b
Organic 3.2 1.05
Semi - detached 3.0 1.12
embedded 2.8 1.20
Bảng 2-5. Phân loại chế độ phát triển trong COCOMO trung cấp
2.2.2.3 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.
2.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 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
Chương 2
21
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ể, dù giá 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.
2.3 Kết hợp Phương pháp Phân tích Điểm Chức
năng với Mô hình Giá Cấu thành (FPA và
COCOMO)
2.3.1 Nội dung kết hợp
Khi phân tích yêu cầu thì có thể tính được FP nhưng chưa có thông tin về LOC.
Phương pháp FPA có thể được dùng cùng với mô hình COCOMO để ước lượng các
tài nguyên cần thiết cho việc phát triển. Điều này được thực hiện trước hết xác định
xem bao nhiêu dòng lệnh cần thiết để xây dựng một điểm chức năng (tức tỉ lệ
LOC/FP). Sau đó nhân giá trị này với số điểm chức năng của hệ thống để có được tổng
số dòng lệnh (LOC hay KLOC) của hệ thống, cái mà có thể dùng trong COCOMO.
Đối với mỗi điểm chức năng, số dòng lệnh để thi hành nó lại phụ thuộc vào môi
trường lập trình và vào những năm 90, các thống kê đã được tiến hành và thấy rằng tỉ
lệ LOC/FP trung bình trên một số dự án đưa ra như trong Bảng 2-6.
Chương 2
22
Ngôn ngữ lập trình Tỷ lệ LOC/FP
Assembly 320
C 128
COBOL 106
FORTRAN 106
Pascal 90
C++ 64
Ada95 53
Visual Basic 32
Smalltalk 22
SQL 12
Bảng 2-6. Tỉ lệ LOC/FP cho phép kết hợp FPA và COCOMO. Nguồn:[11] Trương Ninh
Thuận, slide bài giảng môn Kỹ nghệ phần mềm cho lớp K51CD, chương 3b.
2.3.2 Đánh giá phép kết hợp
Phép chuyển đơn vị tự FP sang LOC để dùng trong COCOMO giúp cho có thể áp
dụng COCOMO sớm trong vòng đời phát triển dự án. Nhưng để có được ước lượng
đáng tin cậy thì cũng rất khó. Trước hết là việc xác định tỉ lệ LOC/FP, dùng cho phép
chuyển đơn vị kích cỡ. Giá trị đề xuất chỉ là giá trị trung bình theo kinh nghiệm và ở
trong mỗi hệ thống thì giá trị này có thể thay đổi rất lớn tùy theo độ phức tạp của xử lý
bên trong của mỗi chức năng. Thứ hai, quay trở lại vấn đề lượng tri thức chứa trong
một số lượng dòng lệnh ở các ngôn ngữ khác nhau đã đề cập ở đánh giá mô hình
COCOMO, lại nảy sinh vấn đề không hợp lý. Ta có thể thấy rằng với cùng một FP thì
có số lượng LOC rất khác nhau đối với các ngôn ngữ khác nhau, dẫn đến các kết quả
theo COCOMO cũng rất khác nhau, trong khi lượng tri thức trong chúng là như nhau.
Trong phép kết hợp thì có thể dùng COCOMO cơ sở hoặc COCOMO trung cấp, còn
COCOMO nâng cao thực chất chỉ là COCOMO trung cấp ở từng pha phát triển.
Chương 2
23
Nếu ta dùng COCOMO cơ sở cho phép kết hợp, thì các giá trị kết quả không thay đổi
nhiều ý nghĩa so với đơn vị FP của FPA, do không có yếu tố điều chỉnh. Tức là, phép
kết hợp vẫn có bản chất là phép FPA. Do đó, những điểm yếu của FPA vẫn giữ nguyên
mà lại phải quan tâm đến những khó khăn trong việc chuyển đơn vị kích cỡ từ FP sang
LOC như đã nêu ở trên.
Nếu ta dùng COCOMO trung cấp cho phép kết hợp, thì ta đã xét thêm các yếu tố môi
trường cho FPA, mà vốn nó là thiếu, nhưng những điểm yếu khác của cả FPA và
COCOMO đã nêu trong đánh giá của 2 phương pháp thì vẫn tồn tại.
Như vậy cách kếp hợp FPA và COCOMO chỉ giúp chuyển đơn vị kích cỡ FPs của
phép phân tích FPA sang một phép tính toán số học để ước lượng giá (nỗ lực và thời
gian) giúp cho việc quản trị dự án, chứ không khắc phục được những nhược điểm
thuộc về bản chất của mỗi thành phần. Tuy vậy, cách dùng kết hợp vẫn là một gợi ý tốt
để đưa ra các giá trị gợi ý cho việc quản trị, theo một phương pháp đã được hiệu chỉnh,
giúp cho việc lập lịch và lên kế hoạch, hơn là việc tính toán không có phương pháp
hoặc không có một phép tính toán nào trợ giúp.
24
PHẦN 2
ƯỚC LƯỢNG DỰ ÁN PHẦN MỀM
THEO ĐIỂM CA SỬ DỤNG
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
25
Chương 3
GIỚI THIỆU PHƯƠNG PHÁP ƯỚC
LƯỢNG DỰ ÁN PHẦN MỀM THEO
ĐIỂM CA SỬ DỤNG
(USE CASE POINT)
3.1 Tóm lược
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 ca sử dụng
Như được đặc tả trong ([4] Jacobson, 2005), ca sử dụng mô tả những cái mà tác nhân
muốn hệ thống thực hiện. Các ca sử dụng 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 ước lượng 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 ca sử dụng.
Năm 1993, Gustav Karner đã sáng tạo ra kĩ thuật ước lượng Điểm Ca Sử dụng (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. Điểm ca sử dụng 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
ước lượng 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 ước lượng cũ đã quá nổi tiếng
trong ngành công nghiệp phần mềm.
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
26
Kĩ thuật ước lượng 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 ước lượng
đáng tin cậy sớm trong vòng đời dự án.
3.2 Nội dung phương pháp
Phương pháp ước lượng UCP đánh giá kích cỡ của dự án theo một đơn vị gọi là Điểm
Ca Sử dụng. Số Điểm Ca Sử dụng đưa cho ta một ước lượng của kích cỡ mà có thể
được ánh xạ sang đơn vị [người – giờ] để phát triển các pha khác nhau theo quy trình
Hướng đối tượng hay toàn bộ hệ thống.
3.2.1 Tính số Điểm Ca Sử dụng (UCPs)
Phương pháp bắt đầu với việc đo chức năng của hệ thống dựa trên biểu đồ ca sử dụng,
đưa ra kết quả là một số được gọi là Điểm Ca Sử dụng Chưa được điều chỉnh (UUCPs
– Unadjusted Use Case Points). Các Yếu tố Kĩ thuật liên quan trong việc phát triển
chức năng được đánh giá, tương tự như trong Phân tích Điểm Chức năng, để đưa ra kết
quả là Yếu tố Độ phức tạp Kĩ thuật. Bước cuối cùng trong ước lượng là một tính toán
khác với phương pháp Điểm Chức năng và đưa ra một yếu tố mới được gọi là Yếu tố
Độ phức tạp Môi trường.
Kết quả cuối cùng của phép đánh giá là số Điểm Ca Sử dụng (UCPs – Use Case
Points), là tích của 3 thừa số được mô tả ở trên. Khái quát, phép đánh giá số Điểm Ca
sử dụng có 4 bước:
- Tính Điểm Ca Sử dụng Chưa được điều chỉnh
- Tính Yếu tố Độ phức tạp Kĩ thuật
- Tính Yếu tố Độ phức tạp Môi trường
- Tính số Điểm Ca Sử dụng của dự án
Sau đây là tính toán cụ thể ở các bước như được đưa ra trong các tài liệu ([5] Karner,
1993), ([8] Schneider, 2001).
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
27
3.2.1.1 Tính số Điểm Ca Sử dụng Chưa được điều chỉnh (UUCPs –
Unadjusted Use Case Points)
Số Điểm Ca Sử dụng Chưa được Điều chỉnh (UUCPs - Unadjusted Use Case Points)
được tính dựa trên hai tính toán sau:
- Đếm số Ca Sử dụng sau khi đánh Trọng số (WUCs – Weighted Use Cases) dựa
trên tổng số các hoạt động (hoặc các bước) được tính đến trong tất cả các kịch
bản ca sử dụng.
- Đếm số Tác nhân sau khi đánh Trọng số (WAs – Weight Actors) dựa trên độ
phức tạp kết hợp của tất cả các Tác nhân Ca sử dụng.
Tính toán cụ thể:
Bước 1: Đếm số Ca Sử dụng sau khi đánh Trọng số (WUCs)
Các ca sử dụng riêng lẻ được phân loại thành Đơn giản, Trung bình hay Phức tạp, và
được đánh trọng số phụ thuộc vào số các giao dịch mà chúng chứa, Bảng 3-1. Chỉ có
các ca sử dụng cụ thể được đếm, tức là không tính đến các một ca sử dụng đóng vai trò
giao diện.
Kiểu Ca sử dụng Mô tả Trọng số
Đơn giản Một ca sử dụng là đơn giản nếu kịch bản
của nó có tới 3 giao dịch hoặc ít hơn; ta
có thể thực thi hành nó với tới ít hơn 5
lớp phân tích.
5
Bình thường Một ca sử dụng là trung bình nếu kịch
bản của nó có từ 4 đến 7 giao dịch; sự thi
hành của nó đòi hỏi từ 5 đến 10 lớp phân
tích.
10
Phức tạp Một ca sử dụng là phức tạp nếu kịch bản
của nó có trên 7 giao dịch; sự thi hành
của nó đòi hỏi trên 10 lớp phân tích.
15
Bảng 3-1. Phân loại và đánh trọng số ca sử dụng trong UCP
Một “giao dịch” của ca sử dụng là một tập các hành động được thực hiện trọn vẹn
hoặc hoàn toàn không được thực hiện. Nó không đơn thuần là khái niệm “giao dịch”
như trong cơ sở dữ liệu. Một giao dịch use case có thể chứa các thao tác cơ sở dữ liệu,
nhưng ngoài ra nó còn chứa thêm các hoạt động khác nữa, ví dụ các kích thích của tác
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
28
nhân, các thao tác khác của hệ thống. Theo mô tả của ([2] Collaris, 2009), một giao
dịch là một “vòng tròn” hành động từ người dùng tới hệ thống quay lại người dùng.
Một “giao dịch” không phải là một bước của ca sử dụng, một kích thích từ tác nhân
(có thể có nhiều kích thích từ tác nhân tới hệ thống nhưng không có chiều ngược lại),
một bước hệ thống hay một giao dịch cơ sở dữ liệu. Giữ giao dịch ở cấp độ hợp lý sẽ
cho ước lượng chính xác hơn, điều này có được nhờ kinh nghiệm áp dụng trong quá
khứ.
WUCs được tính bằng cách đếm số lượng ca sử dụng thuộc mỗi loại, nhân số lượng
mỗi loại ca sử dụng với trọng số của nó và cộng các tích.
3
1i
ii WnWUCs
trong đó:
WUCs : số lượng Ca Sử dụng đếm được sau khi đánh Trọng số
ni : số lượng ca sử dụng loại thứ i (đơn giản, trung bình, phức tạp)
Wi : trọng số của loại ca sử dụng thứ i
Một ví dụ về việc đếm này được đưa ra như Bảng 3-2.
Kiểu Ca
sử dụng
Mô tả Trọng số Số lượng
ca sử dụng
Kết quả
Đơn giản Một ca sử dụng là đơn giản nếu
kịch bản của nó có tới 3 giao dịch
hoặc ít hơn; ta có thể thực thi
hành nó với tới ít hơn 5 lớp phân
tích.
5 8 40
Bình
thường
Một ca sử dụng là trung bình nếu
kịch bản của nó có từ 4 đến 7 giao
dịch; sự thi hành của nó đòi hỏi từ
5 đến 10 lớp phân tích.
10 12 120
Phức tạp Một ca sử dụng là phức tạp nếu
kịch bản của nó có trên 7 giao
dịch; sự thi hành của nó đòi hỏi
trên 10 lớp phân tích.
15 4 60
WUCs = 220
Bảng 3-2. Ví dụ đếm số ca sử dụng sau khi đánh trọng số
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
29
Bước 2: Đếm số Tác nhân sau khi đánh Trọng số (WAs)
Theo một lối quen thuộc, các Tác nhân được phân loại thành Đơn giản, Bình thường
hay Phức tạp dựa trên các tương tác của chúng. Chỉ có các tác nhân cụ thể được tính,
không đếm tác nhân đóng vai trò giao diện.
Kiểu tác nhân Mô tả Trọng số
Đơn giản Một tác nhân là đơn giản nếu nó biểu
diễn một hệ thống khác với một API xác
định (Application Programming
Interface)
1
Bình thường Một tác nhân là trung bình nếu nó là:
1. Một tương tác với một hệ thống khác
thông qua một giao thức, ví dụ TCP
2. Một tương tác con người với một giao
diện dòng lệnh
2
Phức tạp Một tác nhân là phức tạp nếu nó là một
tương tác con người thông qua một giao
diện người dùng đồ họa
3
Bảng 3-3. Phân loại và đánh trọng số tác nhân trong UCP
WAs được tính bằng cách đếm số lượng tác nhân thuộc mỗi loại, nhân số lượng mỗi
loại tác nhân với trọng số của nó và cộng các tích.
3
1i
ii WnWAs
trong đó:
WAs : tổng số lượng Tác nhân sau khi đánh Trọng số
ni : số lượng tác nhân loại thứ i (đơn giản, trung bình, phức tạp)
Wi : trọng số của loại tác nhân thứ i
Tiếp tục ví dụ ở phần trước, đếm số lượng tác nhân sau khi đánh trọng số ở Bảng 3-4.
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
30
Kiểu tác
nhân
Mô tả Trọng số Số lượng
tác nhân
Kết quả
Đơn giản Một tác nhân là đơn giản nếu nó
biểu diễn một hệ thống khác với
một API xác định (Application
Programming Interface)
1 8 8
Bình
thường
Một tác nhân là trung bình nếu nó
là:
3. Một tương tác với một hệ thống
khác thông qua một giao thức,
ví dụ TCP
4. Một tương tác con người với
một giao diện dòng lệnh
2 12 24
Phức tạp Một tác nhân là phức tạp nếu nó là
một tương tác con người thông qua
một giao diện người dùng đồ họa
3 4 12
WAs = 44
Bảng 3-4. Ví dụ đếm số tác nhân sau khi đánh trọng số
Bước 3: Tính tổng UUCPs
Số Điểm Ca Sử dụng Chưa được điều chỉnh được tính bằng cách cộng số lượng Ca Sử
dụng sau khi đánh Trọng số và số lượng Tác nhân sau khi đánh Trọng số.
WAsWUCsUUCPs
trong đó:
UUCPs: số Điểm Ca Sử dụng Chưa được điều chỉnh
WUCs : số Ca Sử dụng sau khi đánh Trọng số
WAs : số Tác nhân sau khi đánh Trọng số
Đối với ví dụ đưa ra trong Bảng 3-2 và Bảng 3-4:
UUCPs = 220 + 44 = 264
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
31
3.2.1.2 Tính Yếu tố Độ phức tạp Kĩ thuật
Điểm Ca Sử dụng Chưa được điều chỉnh sẽ được điều chỉnh bởi Yếu tố Độ phức tạp
Kĩ thuật (TCF). TCF là gần tương tự như trong Phân tích Điểm Chức năng, khác biệt
là tác giả đã thêm một số và bớt một số yếu tố để phù hợp với quy trình Hướng đối
tượng. Ngoài ra, các yếu tố được đánh trọng số tổng quát dựa trên kinh nghiệm về tác
động tương đối của mỗi yếu tố.
Đối với mỗi dự án riêng lẻ, các yếu tố kĩ thuật được đánh giá bởi đội phát triển và được gán
cho một tỉ lệ ảnh hưởng từ 0 đến 5 theo độ phức tạp nhận thức được (dựa vào kinh nghiệm).
Các ứng dụng đa luồng thì cần nhiều kĩ năng và thời gian hơn so với các ứng dụng đơn luồng,
chẳng hạn, như là làm các các ứng dụng có khả năng sử dụng lại. Một tỉ lệ bằng 0 có nghĩa là
yếu tố kĩ thuật không liên quan gì tới dự án này; 3 là trung bình; 5 có nghĩa là nó có ảnh
hưởng mạnh.
Trọng số của mỗi yếu tố được nhân với độ phức tạp nhận thức của nó để đưa ra yếu tố tính
toán của nó. Các yếu tố tính toán được cộng lại để đưa ra yếu tố tổng cộng (totalF – Total
Factor).
Yếu tố totalF không trực tiếp làm thay đổi UUCPs, ta đưa nó vào Yếu tố độ phức tạp
kĩ thuật TCF bằng cách nhân totalF với 0.01 và cộng với 0.6. Các công thức để tính
TCF:
13
1i
ii WTtotalF
totalFCCTCF *21
Hoặc có thể dùng công thức tổng hợp sau:
13
1
21
i
ii WTCCTCF
trong đó:
C1= 0.6
C2= 0.01
Wi : trọng số của yếu tố kĩ thuật thứ i
Ti : tỉ lệ ảnh hưởng(độ phức tạp nhận thức) của yếu tố thứ i trong dự án
totalF : Yếu tố ảnh hưởng tổng cộng mặt kĩ thuật
TCF : Yếu tố Độ phức tạp Kĩ thuật
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
32
Yếu tố kĩ thuật Mô tả Trọng số
T1 Hệ thống phân tán 2
T2 Các mục tiêu hiệu năng ứng
dụng, về mặt đáp ứng hay
thông lượng
1
T3 Hiệu quả người dùng cuối
(trực tuyến)
1
T4 Xử lý nội bộ phức tạp 1
T5 Tính sử dụng lại, mã phải có
khả năng để dùng lại trong các
ứng dụng khác
1
T6 Dễ cài đặt 0.5
T7 Dễ sử dụng 0.5
T8 Di động (portablity) 2
T9 Dễ thay đổi (Changeability) 1
T10 Đồng thời 1
T11 Các đặc điểm an ninh đặc biệt 1
T12 Cung cấp truy cập trực tiếp cho
các bên thứ 3
1
T13 Các chính sách đào tạo người
dùng đặc biệt
1
Bảng 3-5. Trọng số của 13 yếu tố kĩ thuật trong UCP
Theo chú ý của tác giả, ([5] Karner, 1993), nếu một yếu tố không phải là quan trọng, mà
cũng không phải là không liên quan, thì lấy tỉ lệ ảnh hưởng của nó là 3. Nếu tất cả các yếu tố
đều có tỉ lệ ảnh hưởng là 3 thì TCF ≈ 1.
Tiếp tục ví dụ đã nêu ở các phần trước, sử dụng các giá trị tỉ lệ dự án mẫu cho các yếu tố, yếu
tố tổng cộng được tính như Bảng 3-6. Sau đó tính TCF.
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
33
Yếu tố kĩ
thuật
Mô tả yếu tố Trọng số Tỉ lệ dự án Kết quả
T1 Hệ thống phân tán 2 5 10
T2 Các mục tiêu hiệu năng ứng dụng,
về mặt đáp ứng hay thông lượng
1 3 3
T3 Hiệu quả người dùng cuối (trực
tuyến)
1 5 5
T4 Xử lý nội bộ phức tạp 1 5 5
T5 Tính sử dụng lại, mã phải có khả
năng để dùng lại trong các ứng
dụng khác
1 3 3
T6 Dễ cài đặt 0.5 3 1.5
T7 Dễ sử dụng 0.5 3 1.5
T8 Di động (portablity) 2 0 0
T9 Tùy biến (Changeability) 1 5 5
T10 Đồng thời 1 0 0
T11 Các đặc điểm an ninh đặc biệt 1 5 5
T12 Cung cấp truy cập trực tiếp cho các
bên thứ 3
1 0 0
T13 Các chính sách đào tạo người dùng
đặc biệt
1 3 3
Yếu tố
tổng cộng
totalF = 42
Bảng 3-6. Ví dụ tính Yếu tố Độ phức tạp Kĩ thuật trong UCP
Đối với Bảng 3-6, yếu tố tổng cộng là 42, còn Yếu tố Độ phức tạp Kĩ thuật là:
TCF = 0.6 + 0.01 * 42 = 1.02
3.2.1.3 Tính Yếu tố Độ phức tạp Môi trường (ECF – Environmental
Complexity Factor)
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
34
Mức độ kinh nghiệm của mỗi thành viên dự án có thể có một ảnh hưởng lớn lên quá trình
phát triển dự án. Mỗi dự án được phát triển trong một môi trường và chịu ảnh hưởng của môi
trường đó. Có 8 Yếu tố Môi trường được tổng quát theo nhận định kinh nghiệm. Mỗi yếu tố
môi trường được đánh giá và cho trọng số tổng quát theo kinh nghiệm, Bảng 3-7.
Yếu tố môi
trường
Mô tả Trọng số
E1 Quen thuộc với UML 1.5
E2 Kinh nghiệm ứng dụng 0.5
E3 Kinh nghiệm hướng đối tượng 1
E4 Khả năng phân tích 0.5
E5 Động lực 1
E6 Các yêu cầu ổn định 2
E7 Những nhân lực bán thời gian -1
E8 Ngôn ngữ lập trình khó -1
Bảng 3-7. Trọng số của 8 yếu tố môi trường trong UCP
Để đánh giá ảnh hưởng của các yếu tố trên mỗi dự án riêng lẻ, mỗi yếu tố được xét và
được gán cho một tỉ lệ ảnh hưởng. Đối với các yếu tố từ E1 – E4, tỉ lệ 0 có nghĩa là không
có kinh nghiệm trong dự án, 3 nghĩa là trung bình, và 5 nghĩa là thành thạo. Đối với E5, 0
nghĩa là không có động lực trong dự án, 3 nghĩa là trung bình, và 5 nghĩa là động lực lớn. Đối
với E6, 0 có nghĩa là các yêu cầu không thay đổi, 3 có nghĩa là tổng số của thay đổi được
mong đợi bình thường, và 5 nghĩa là các yêu cầu cực kì không ổn định. Đối với E7, 0 có
nghĩa là không có nhân viên kĩ thuật bán thời gian, 3 nghĩa là khoảng một nửa của đội là bán
thời gian, và 5 có nghĩa là tất cả đội là bán thời gian. Đối với E8, 0 có nghĩa là một ngôn ngữ
lập trình dễ sử dụng được lên kế hoạch, 3 nghĩa là ngôn ngữ khó bình thường, và 5 nghĩa là
một ngôn ngữ rất khó được lên kế hoạch cho dự án.
Đối với mỗi yếu tố, nhân tỉ lệ tác động của nó với trọng số của nó từ bảng. Cộng các giá trị
kết quả cùng nhau để lấy Yếu tố Tổng cộng (totalF). Yếu tố Độ phức tạp Môi trường được
tính bằng cách nhân totalF với -0.03 và cộng 1.4. Các công thức để tính ECF:
8
1i
ii WEtotalF
totalFCCECF *21
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
35
Hoặc có thể dùng công thức tổng hợp sau:
8
1
21
i
ii WECCECF
trong đó:
C1= 1.4
C2= -0.03
Wi : trọng số của yếu tố môi trườngs thứ i
Esi : tỉ lệ ảnh hưởng của yếu tố thứ i trong dự án
totalF : Yếu tố ảnh hưởng tộng cộng mặt môi trường
ECF : Yếu tố Độ phức tạp Môi trường
Lại theo chú ý của tác giả, ([5] Karner, 1993), nếu một yếu tố không phải là quan trọng, mà
cũng không phải là không liên quan, thì lấy tỉ lệ ảnh hưởng của nó là 3. Nếu tất cả các yếu tố
đều có tỉ lệ ảnh hưởng là 3 thì ECF ≈ 1.
Sử dụng các giá trị tỉ lệ dự án mẫu cho các yếu tố, yếu tố tổng cộng được tính như Bảng 3-8.
Sau đó tính ECF.
Yếu tố kinh
nghiệm
Mô tả yếu tố Trọng số Tỉ lệ dự án Kết quả
E1 Quen thuộc với UML 1.5 4 6
E2 Kinh nghiệm ứng dụng 0.5 2 1
E3 Kinh nghiệm hướng đối tượng 1 4 4
E4 Khả năng phân tích 0.5 4 2
E5 Động lực 1 4 0
E6 Các yêu cầu ổn định 2 2 4
E7 Những nhân lực bán thời gian -1 0 0
E8 Ngôn ngữ lập trình khó -1 1 -1
Yếu tố tổng
cộng
totalF = 16
Bảng 3-8. Ví dụ tính Yếu tố Độ phức tạp Môi trường trong UCP
Đối với Bảng 3-8, yếu tố tổng cộng là 16, còn Yếu tố Độ phức tạp Môi trường là:
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
36
ECF = 1.4 +(- 0.03 * 16) = 0.92
3.2.1.4 Tính số Điểm Ca Sử dụng
Đây là bước cuối cùng để đưa ra kích cỡ của dự án trong một đơn vị được gọi là số
Điểm Ca Sử dụng (UCPs – Use Case Points). UCPs được tính bằng biểu thức sau:
ECFTCFUUCPsUCPs **
trong đó:
UCPs : số Điểm Ca sử dụng
UUCPs: số Điểm Ca sử dụng Chưa được điều chỉnh
TCF : Yếu tố Độ phức tạp Kĩ thuật
ECF : Yếu tố Độ phức tạp Môi trường
Tiếp tục ví dụ đã nêu ở các phần trên. Các thừa số của công thức đã được tính, bây giờ,
tổng Điểm Ca Sử dụng của dự án là:
UCPs = 264 * 1.02 * 0.92 ≈ 248
3.2.2 Ước lượng nỗ lực từ số Điểm Ca Sử dụng
Theo như mô tả của tác giả, ([5] Karner, 1993), từ UCPs có thể ánh xạ sang một đơn vị
khác như số lượng các lớp thi hành hay LOC và từ đó ước lượng nỗ lực [người – giờ]
cần thiết cho dự án với sự trợ giúp của một mô hình như COCOMO chẳng hạn. Nhưng
đề nghị là không nên làm như vậy vì mô hình như COCOMO dùng sự ánh xạ không
phải là tuyến tính.
Qua các phép thống kê số liệu của chính tác giả, ([5] Karner, 1993), để phân tích xem
bao nhiêu tài nguyên cần thiết cho mỗi UCP. Phép phân tích kết quả là xấp xỉ tuyến
tính rằng mỗi UCP cần 20 [người – giờ] để hoàn thành. Điều này là một xấp xỉ đủ tốt
cho hầu hết các dự án. Liên hệ giữa 2 đơn vị này chỉ có dạng đường cong của một biểu
thức lũy thừa với các dự án cực lớn, khi mà năng suất làm việc ở đó thường thấp.
Biến đổi Điểm Ca Sử dụng thành [người – giờ] trên mỗi UCP là một vấn đề của việc
tính toán một cách sử dụng chuẩn, hay tỉ lệ nỗ lực (ER – Effort Rate), và nhân giá trị
đó với số lượng UCP. Một số nghiên cứu thống kê về vấn đề này đã được tiến hành.
Theo đề xuất của RoyClem, ([7] RoyClem, 2005), một số giữa 15 và 30 đựa đưa ra bởi
những chuyên gia. Một giá trị điển hình là 20. Theo ([1] Carroll, 2005), kinh nghiệm
của các đội kĩ nghệ của sự phối hợp Agilis Solution và FPT Software, Hanoi, Vietnam
đã thiết lập tỉ lệ nỗ lực [người – giờ] dự án ở 28 [người – giờ] cho mỗi Điểm Ca Sử
Chương 3 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
37
dụng (28[người – giờ]/UCP). Hơn nữa, kinh nghiệm này cũng phù hợp với ([8]
Schneider, 2001) ở chỗ không phải tất cả các dự án là giống nhau, từ đó phân biệt các
dự án đơn giản với phức tạp bằng cách dùng 20 [người – giờ] cho mỗi Điểm Ca Sử
dụng ở các dự án đơn giản.
Tính tổng nỗ lực [người – giờ] bằng cách nhân UCP với tỉ lệ nỗ lực:
ERUCPsttotalEffor *
Cách xác định ER theo ([8] Schneider, 2001) cụ thể như sau:
Đếm số lượng (count) các tỉ lệ yếu tố của E1 – E6 mà dưới 3 và số lượng các tỉ lệ yếu
tố của E7 – E8 mà trên 3. Nếu tổng số count là bằng hoặc nhỏ hơn 2, thì dùng 20
người – giờ mỗi UCP. Nếu count là 3 hoặc 4, dùng 28 người – giờ cho mỗi UCP. Nếu
count là 5 hoặc lớn hơn thì xem xét việc tổ chức lại đội dự án để các số giảm số lượng
ít nhất nhỏ hơn 5. Một giá trị bằng hoặc lớn hơn 5 chỉ ra rằng dự án này có nguy cơ
đáng kể của sự thất bại với đội dự án dự định.
Tiếp tục ví dụ tính UCPs đã nêu trong phần nội dung phương pháp, đếm count = 1,
chọn ER= 20, nỗ lực của dự án đã được mô tả là:
248 * 20 = 4960 [người – giờ]
Các đơn vị thông dụng hơn là [người – tuần] hay [người – tháng]. Chia [người – giờ]
cho 40[giờ làm việc / tuần] được đơn vị [người – tuần].
4960 /40 = 124 [người – tuần]
Chương 4 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
38
Chương 4
XÂY DỰNG CHƯƠNG TRÌNH TÍNH
TOÁN HỖ TRỢ ƯỚC LƯỢNG
UCP Estimator
4.1 Phát biểu bài toán
Các dự án được phân tích và phát triển theo phương pháp hướng đối tượng. Cần xây
dựng một chương trình để tính toán ước lượng cho dự án theo phương pháp Điểm Ca
Sử dụng (UCP) như được mô tả trong cùng khóa luận.
Tên của chương trình là: UCP Estimator.
Chương trình được viết bằng ngôn ngữ PHP, thao tác trên hệ cơ sở dữ liệu mySQL.
4.2 Phân tích bài toán
4.2.1 Phân tích tổng thể
Một dự án (Project) có thể được chia thành các Mô – đun (Module) ở các mức. Mỗi
mô – đun được coi như một dự án độc lập với các mô – đun khác để thực hiện ước
lượng trên mô – đun đó, một dự án tổng thể được coi như mô – đun ở mức cao nhất.
Tuy vậy, chương trình chỉ thực hiện ước lượng trên một mô – đun ở một mức mà
không quan tâm đến các mô – đun khác, dù ở cùng mức hay khác mức (kể các các mô
– đun con). Công việc phân chia và quản lý các mô – đun là của quản trị dự án.
Mỗi mô - đun có thể được Ước lượng (Estimates) nhiều lần. Các số liệu và kết quả của
mỗi lần ước lượng của mỗi mô - đun phải được lưu lại như là dữ liệu lịch sử để phục
vụ cho các ước lượng khác trong tương lai.
Chương trình cần thực hiện được các chức năng:
- Tính ước lượng mới
- Tìm kiếm thông tin ước lượng cũ
Chương 4
39
4.2.2 Phân tích cụ thể chức năng
Quy trình tính toán của chức năng “Tính ước lượng mới” như được mô tả trong
Chương 3 cùng khóa luận.
Việc tìm kiếm thông tin ước lượng cũ có thể được thực hiện theo 2 cách:
- Tìm kiếm trực tiếp đến Ước lượng. Người dùng mong muốn xem lại thông tin
của một Ước lượng đã thực hiện. Người dùng nhập thông tin để tìm kiếm Ước
lượng, chương trình trả về các Ước lượng hợp lý với từ khóa tìm kiếm.
- Tìm kiếm Mô – đun: người dùng mong muốn xem lại thông tin về các ước
lượng đã thực hiện của một Mô – đun. Người dùng nhập thông tin Mô – đun để
tìm kiếm, chương trình trả về các Mô – đun hợp lý với từ khóa tìm kiếm
4.3 Đặc tả chương trình
4.3.1 Biểu đồ ca sử dụng của chương trình
Sau đây là biểu đồ ca sử dụng tổng thể của chương trình:
Hình 4-1. Biểu đồ ca sử dụng tổng thể - UCP Estimator
Biểu đồ ca sử dụng tổng thể của chương trình chỉ có 2 tác nhân. Các kịch bản ca sử
dụng được miêu tả như trong các biểu đồ hoạt động ở phần sau.
Chương 4
40
Kịch bản ca sử dụng số 1:
Tác nhân
Người dùng
Hệ thống
Luồng sự kiện 1. Chọn thực hiện Ước
lượng mới
2. Yêu cầu nhập thông tin định
danh Ước lượng mới
3. Nhập thông tin định
danh Ước lượng
4. Yêu cầu nhập thông tin để
tính UUCPs
5. Nhập thông tin tính
UUCPs
6. Yêu cầu nhập thông để tính
TCF
7. Nhập thông tin tính TCF 8. Yêu cầu nhập thông để tính
ECF
9. Nhập thông tin tính ECF 10. Yêu cầu nhập ER
11. Nhập ER 12. Trả về totalEffort
Bảng 4-8. Kịch bản ca sử dụng “Thực hiện ước lượng mới” – UCP Estimator
Kịch bản ca sử dụng số 2:
Tác nhân
Người dùng
Hệ thống
Luồng sự kiện 1. Chọn Tìm kiếm 2. Yêu cầu nhập thông tin tìm
kiếm
3. Nhập thông tin tìm kiếm 4. Trả lại kết quả
Bảng 4-9. Kịch bản ca sử dụng “Tìm kiếm ước lượng lịch sử” – UCP Estimator
4.3.2 Các biểu đồ hoạt động
4.3.2.1 Biểu đồ hoạt động của ca sử dụng số 1
(số được viết trong biểu đồ là số thứ tự của giao dịch ca sử dụng)
Chương 4
41
Hình 4-2. Biểu đồ hoạt động của ca sử dụng "Thực hiện Ước lượng mới" - UCP Estimator
4.3.2.2 Biểu đồ hoạt động của ca sử dụng số 2
(số được viết trong biểu đồ là số thứ tự của giao dịch ca sử dụng)
Hình 4-3. Biểu đồ hoạt động của ca sử dụng "Tìm kiếm Ước lược lịch sử" - UCP Estimator
Chương 4
42
4.4 Thiết kế logic hoạt động cho chương trình
4.4.1 Xác định các lớp phân tích
Xem xét kịch bản hoạt động trong biểu đồ hoạt động của ca sử dụng “Thực hiện Ước
lượng mới”, đề xuất các lớp phân tích như sau:
Người dùng (tác nhân)
Giao diện chương trình (lớp biên)
Điều khiển quy trình ước lượng (lớp điều khiển)
Thông tin ước lượng (lớp thực thể)
Xem xét kịch bản hoạt động trong biểu đồ hoạt động của ca sử dụng “Tìm kiếm ước
lượng lịch sử”, đề xuất các lớp phân tích như sau:
Người dùng (tác nhân)
Giao diện chương trình (lớp biên)
Điều khiển tìm kiếm (lớp điều khiển)
Thông tin ước lượng (lớp thực thể)
4.4.2 Các biểu đồ cộng tác
4.4.2.1 Biểu đồ cộng tác cho ca sử dụng số 1
Chương 4
43
Hình 4-4. Biểu đồ cộng tác cho ca sử dụng "Thực hiện ước lượng mới" - UCP Estimator
4.4.2.2 Biểu đồ cộng tác cho ca sử dụng số 2
Hình 4-5. Biểu đồ cộng tác cho ca sử dụng "Tìm kiếm ước lượng lịch sử" - UCP Estimator
Chương 4
44
4.4.3 Các biểu đồ tuần tự
4.4.3.1 Biểu đồ tuần tự cho ca sử dụng số 1
Hình 4-6. Biểu đồ tuần tự cho ca sử dụng "Thực hiện ước lượng mới" - UCP Estimator
Chương 4
45
4.4.3.2 Biểu đồ tuần tự cho ca sử dụng số 2
Hình 4-7. Biểu đồ tuần tự cho ca sử dụng "Tìm kiếm ước lượng lịch sử" - UCP Estimator
4.5 Thiết kế cơ sở dữ liệu
4.5.1 Phân tích bài toán để xây dựng cơ sở dữ liệu
Mỗi mô - đun có thể được Ước lượng (Estimates) nhiều lần. Các số liệu và kết quả của
mỗi lần ước lượng của mỗi mô - đun phải được lưu lại như là dữ liệu lịch sử để phục
vụ cho các ước lượng khác trong tương lai.
Mỗi một mô – đun có thể được ước lượng nhiều lần, hay có nhiều ước lượng, nhưng
mỗi một ước lượng thì chỉ dựa trên một phân tích (một tập Tác nhân, một tập Ca sử
dụng) cụ thể, chỉ xét trên một đội phát triển với các yếu tố ảnh hưởng cụ thể, và chỉ xét
trong một môi trường với các yếu tố ảnh hưởng cụ thể.
Mỗi Loại Tác nhân (Actor_Types), mỗi Loại Ca Sử dụng (UseCase_Types), mỗi Yếu
tố Kĩ thuật (Technical_Factors), mỗi Yếu tố Môi trường (Environment_Factors) được
đánh trọng số trước theo phương pháp Điểm Ca Sử dụng để phục vụ cho các ước
lượng. Mỗi ước lượng có một số lượng (quantity) cụ thể của mỗi loại tác nhân, có một
số lượng cụ thể của một loại ca sử dụng. Mỗi ước lượng chịu ảnh hưởng của mỗi yếu
tố kĩ thuật và môi trường theo một tỉ lệ (rate) xác định.
Chương 4
46
Mỗi mô – đun được xác định bởi mã mô – đun, tên mô – đun, mô tả mô – đun
(mod_code, mod_name, mod_description)
Mỗi ước lượng được xác định bởi mã ước lượng, tên ước lượng, mô tả ước lượng
(est_code, est_name, est_description)
Mỗi loại tác nhân được xác định bởi bởi tên loại tác nhân, mô tả loại tác nhân, trọng số
của loại tác nhân (act_type_name, act_type_description, act_type_weight)
ví dụ tên loại tác nhân: Simple, Average, Complex, …
Mỗi loại ca sử dụng được xác định bởi tên loại ca sử dụng, mô tả loại ca sử dụng,
trọng số của loại ca sử dụng (uc_type_name, uc_type_description, uc_type_weight)
ví dụ tên loại ca sử dụng: Simple, Average, Complex
Mỗi yếu tố kĩ thuật được xác định bởi tên yếu tố kĩ thuật, mô tả yếu tố kĩ thuật, trọng
số của yếu tố kĩ thuật (tech_factor_name, tech_factor_description,
tech_factor_weight)
ví dụ tên yếu tố kĩ thuât: T1, T2, T3, …
Mỗi yếu tố môi trường được xác định bởi tên yếu tố môi trường, mô tả yếu tố môi
trường, trọng số của yếu tố môi trường (env_factor_name, env_factor_description,
env_factor_weight)
ví dụ tên yếu tố môi trường: E1, E2, E3
Trong tương lai, phương pháp có thể được bổ sung thêm các loại tác nhân, các loại ca
sử dụng, các yếu tố kĩ thuật, các yếu tố môi trường.
4.5.2 Xây dựng biểu dồ thực thể - liên kết (E-R)
Xác định các tập thực thể:
Mô – đun: Modules(mod_id, mod_code, mod_name, mod_description)
Ước lượng: Estimates(est_id, est_code, est_name, est_description)
Loại Tác nhân: Actor_Types(act_type_id, act_type_name, act_type_description,
act_type_weight)
Loại Ca Sử dụng: UseCase_Types(uc_type_id, uc_type_ name,
uc_type_description, uc_type_weight)
Yếu tố Kĩ thuật: Technical_Factors(tech_factor_id, tech_factor_ name,
tech_factor_description, tech_factor_weight)
Chương 4
47
Yếu tố Môi trường: Environment_Factors(env_factor_id, env_factor_ name,
env_factor_description, env_factor_weight)
Xác định các mối quan hệ:
(0...n) (1...1) Modules Estimates Có
(1...n) (0...n)
Estimates Actors_Types Chứa
quatity
(số lượng tác nhân)
(1...n) (0...n)
Estimates UseCase_Types Chứa
quatity
(số lượng ca sử
dụng)
(1...n) (0...n)
Estimates Technical_Factors Chứa
rate
(tỉ lệ yếu tố kĩ thuật)
(1...n) (0...n)
Estimates Environment_Factors Chứa
rate
(tỉ lệ yếu tố môi
trường)
Chương 4
48
Mô hình E – R:
(1...n)
(0...n)
Environment_Factors
env_factor_id
Chứa rate
(1...n)
(0...n)
Technical_Factors
tech_factor_id
Chứa
rate
(0...n)
(1...1)
Modules
mod_id
Có
(0...n)
(1...n)
Actors_Types
act_type_id
Chứa
quantity
(0...n)
(1...n)
UseCase_Types
uc_type_id
Chứa
quantity
Estimates
est_id
01
02
03
04
05
Hình 4-8. Biểu đồ thực thể-mối quan hệ - UPC Estimator
Chương 4
49
4.5.3 Xây dựng lược đồ quan hệ
Dựa vào tập thực thể và các mối quan hệ của mô hình thực thể - liên kết, ta xây dựng
lược đồ quan hệ như sau:
Modules(mod_id, mod_code, mod_name, mod_description)
Estimates(est_id, est_code, est_name, est_description, mod_id) : xét quan hệ số 01,
chuyển sang lược đồ quan hệ bằng cách thêm khóa ngoài Estimates.mod_id
tham chiếu đến khóa chính Modules.mod_id
Actor_Types(act_type_id, act_type_ name, act_type_description, act_type_weight)
UseCase_Types(uc_type_id, uc_type_ name, uc_type_description, uc_type_weight)
Technical_Factors(tech_factor_id, tech_factor_ name, tech_factor_description,
tech_factor_weight)
Environment_Factors(env_factor_id, env_factor_ name, env_factor_description,
env_factor_weight)
Actor_Type_Contained(est_id, act_type_id, quantity) : xét quan hệ số 02, chuyển
sang lược đồ quan hệ bằng cách thêm vào quan hệ mới
Actor_Type_Contained có khóa chính gồm 2 thành phần tham
chiếu đến 2 khóa Estimates.est_id và Actor_Types.act_type_id
UseCase_Type_Contained(est_id, uc_type_id, quantity) : xét quan hệ số 03, chuyển
sang lược đồ quan hệ bằng cách thêm vào quan hệ mới
UseCase_Type_Contained có khóa chính gồm 2 thành
phần tham chiếu đến 2 khóa Estimates.est_id và
UseCase_Types.uc_type_id
Technical_Factor_Contained(est_id, tech_factor_id, rate) : xét quan hệ số 04, chuyển
sang lược đồ quan hệ bằng cách thêm vào quan hệ mới
Tech_Factor_Contained có khóa chính gồm 2 thành phần
tham chiếu đến 2 khóa Estimates.est_id và
Technical_Factors.tech_factor_id
Environment_Factor_Contained(est_id, env_factor_id, rate) : xét quan hệ số 04,
chuyển sang lược đồ quan hệ bằng cách thêm vào quan hệ
mới Env_Factor_Contained có khóa chính gồm 2 thành phần
Chương 4
50
tham chiếu đến 2 khóa Estimates.est_id và
Environment_Factors.env_factor_id
Chương 5 – Khóa luận tốt nghiệp – Nguyễn Trần Việt
51
Chương 5
ÁP DỤNG VÀ ĐÁNH GIÁ PHƯƠNG
PHÁP ƯỚC LƯỢNG ĐIỂM CA SỬ DỤNG
Chương này sẽ đánh giá phương pháp ước lượng Điểm Ca sử dụng về mặt lý thuyết và
thực tế. Đánh giá về mặt lý thuyết thông qua so sánh với 2 phương pháp truyển thống:
Điểm Chức năng và COCOMO. Đánh giá thực tế trước hết thông qua việc áp dụng
phương pháp vào bài toán cụ thể.
5.1 Áp dụng thực tế
Trong phần này này, em sẽ áp dụng phương pháp Điểm Ca Sử dụng vào 2 bài toán:
- Dự án xây dựng máy rút tiền ATM. Việc xét dự án này giúp cho việc hiểu quy
trình tính toán.
- Dự án xây dựng chương trình tính toán Ước lượng – UCP Estimator – như được
nêu trong Chương 4 cùng khóa luận. Việc xét dự án này là một áp dụng sâu sắc
vào cách dùng phương pháp, vào các yếu tố điều chỉnh số điểm kết quả của
phương pháp.
5.1.1 Bài toán số 1 – Dự án xây dựng mô–đun cho máy rút
tiền ATM
5.1.1.1 Miêu tả dự án
Xây dựng mô – đun hoạt động trên máy ATM có 2 chức năng Rút tiền và Chuyển tiền.
Các module cần thiết khác coi như đã có sẵn.
Các biểu đồ Ca sử dụng (và kịch bản), biểu đồ hoạt động của phân tích dự án được mô
tả ở Phụ lục A trong cùng khóa luận.
5.1.1.2 Ước lượng kích cỡ
tính số Điểm Ca Sử dụng
Bước 1: Tính UUCPs
Tính WUCs:
Chương 5
52
Xem xét biểu đồ hoạt động của các ca sử dụng ở Phụ lục A, để xác định số giao dịch
trong mỗi ca sử dụng. Các giao dịch đã được đánh số thứ tự trong biểu đồ hoạt động.
- Ca sử dụng “Định danh” có 2 giao dịch
- Ca sử dụng “Rút tiền” có 2 giao dịch
- Ca sử dụng “Chuyển tiền” có 4 giao dịch
Từ đó, căn cứ theo tiêu chuẩn xác định loại ca sử dụng của phương pháp Điểm Ca sử
dụng được nêu ở Bảng 3-1, mục 3.2.1.1, ta tính toán UUCPs như sau:
Kiểu Ca
sử dụng
Ca sử dụng Trọng số Số lượng
ca sử dụng
Kết quả
Đơn giản 1. Định danh
2. Rút tiền
5 2 10
Bình
thường
1. Chuyển tiền 10 1 10
Phức tạp 15 0 0
WUCs = 20
Bảng 5-10. Đếm WUCs - dự án ATM
TínhWAs:
Trong biểu đồ ca sử dụng có 1 tác nhân Khách hàng, biểu diễn 1 người tương tác với
hệ thống thông qua giao diện người dùng đồ họa, thuộc loại tác nhân Phức tạp theo
phân loại đưa ra trong Bảng 3-3, mục 3.2.1.1.
Kiểu tác
nhân
Các tác nhân Trọng số Số lượng
tác nhân
Kết quả
Đơn giản 1 0 0
Bình thường 2 0 0
Phức tạp 1. Khách hàng 3 1 3
WAs = 3
Bảng 5-2. Đếm WAs – dự án ATM
Dựa vào Bảng 5-1 và Bảng 5-2, tính:
UUCPs = WUCs + WAs = 20 + 3 = 23
Chương 5
53
Bước 2: Tính TCF
Giả sử tất cả các yếu tố không phải là quan trọng, mà cũng không phải là không liên quan,
lấy tỉ lệ ảnh hưởng của tất cả là 3. Khi đó, như trong phần giới thiệu phương pháp UCP trong
cùng khóa luận, thì TCF ≈ 1.
Bước 3: Tính ECF
Giả sử tất cả các yếu tố không phải là quan trọng, mà cũng không phải là không liên quan,
lấy tỉ lệ ảnh hưởng của tất cả là 3. Khi đó, như trong phần giới thiệu phương pháp UCP trong
cùng khóa luận, thì ECF ≈ 1.
Bước 4: Tính số Điểm Ca sử dụng (UCPs)
UCPs = UUCPs * TCF * ECF = 23 * 1 * 1
= 23 [UCP]
5.1.1.3 Ước lượng nỗ lực
Dùng tỉ lệ nỗ lực ER = 20[người – giờ / UCP] ta có nỗ lực tổng cộng của dự án là:
totalEffort = UCPs * ER = 23 * 20
totalEffort = 460 [người – giờ]
totalEffort = 11.5 [người – tuần]
Dùng tỉ lệ nỗ lực ER = 28[người – giờ / UCP] ta có nỗ lực tổng cộng của dự án là:
totalEffort = UCPs * ER = 23 * 28
totalEffort = 644 [người – giờ]
totalEffort ≈ 16 [người – tuần]
Từ nỗ lực này có thể dùng giá lương tổng quát theo kinh nghiệm để ước lượng chi phí
nhân công của dự án.
5.1.2 Bài toán số 2 – Dự án xây dựng chương trình UCP
Estimator
5.1.2.1 Miêu tả dự án
Dự án thứ 2 chính là dự án xây dựng chương trình tính toán ước lượng UCP Estimator
được mô tả ở Chương 4. Các phân tích bài toán và biểu đồ đã được mô tả đầy đủ ở
Chương 4
Chương 5
54
5.1.2.2 Ước lượng kích cỡ
tính số Điểm Ca Sử dụng
Bước 1: Tính UUCPs
Tính WUCs:
Xem xét biểu đồ hoạt động của các ca sử dụng:
- Xem xét Hình 4-2, mục 4.3.2.1, nhận thấy ca sử dụng “Thực hiện ước lượng
mới” có 5 giao dịch như được đánh số thứ tự, được xếp vào loại Bình thường
- Xem xét Hình 4-3, mục 4.3.2.2, nhận thấy ca sử dụng “Tìm kiếm Ước lượng
lịch sử” có 2 giao dịch, được xếp vào loại Đơn giản
Kiểu Ca
sử dụng
Các ca sử dụng Trọng số Số lượng
ca sử dụng
Kết quả
Đơn giản 1. Tìm kiếm Ước lượng lịch sử 5 1 5
Bình
thường
1. Thực hiện Ước lượng mới 10 1 10
Phức tạp 15 0 0
WUCs = 15
Bảng 5-3. Đếm WUCs - dự án UCP Estimator
Tính WAs:
Tác nhân “Người dùng” trong biểu đồ ca sử dụng của chương trình có vẻ như biểu
diễn một người tương tác qua một giao diện đồ họa, và được xếp vào loại tác nhân
Phức tạp theo UCP. Tuy vậy, trong chương trình không xây dựng tác nhân này (không
có lớp thực thể biểu diễn tác nhân này), mà chỉ xây dựng các chức năng tính toán, nên
sẽ không tính đến tác nhân này khi ước lượng. Chỉ đếm điểm cho tác nhân khi xây
dựng một lớp đối tượng riêng để biểu diễn tác nhân với các thuộc tính (định danh, tên,
số điện thoại, …) như tác nhân “Khách hàng” trong Bài toán 1 có các thuộc tính(tên,
mã số thẻ, mã PIN, …). Không đếm tác nhân >, vì đó chính là hệ thống ta
xây dựng.
Chương 5
55
Kiểu tác
nhân
Các tác nhân Trọng số Số lượng
tác nhân
Kết quả
Đơn giản 1 0 0
Bình thường 2 0 0
Phức tạp 3 0 0
WAs = 0
Bảng 5-4. Đếm WAs - dự án UCP Estimator
Dựa vào Bảng 5-3 và Bảng 5-4, tính:
UUCPs = WUCs + WAs = 15 + 0 = 15
Bước 2: Tính TCF
Xem xét độ phức tạp mặt kĩ thuật của dự án để cho điểm ảnh hưởng(tỉ lệ dự án) của
các yếu tố được đưa ra trong Bảng 3-5, mục 3.2.1.2:
- T1: Hệ thống phân tán = 0 (không yêu cầu yếu tố này trong dự án)
- T2: Mục tiêu hiệu năng = 0 (không cần quan tâm với một chương trình tiêu tốn
ít tài nguyên đối với hệ thống máy tính hiện đại bây giờ)
- T3: Hiệu quả người dùng cuối trực tuyến = 3 (trung bình)
- T4: Xử lý nội bộ phức tạp = 1 (chỉ có các phép tính tuyến tính)
- T5: Tính sử dụng lại mã = 4 (mô – đun ước lượng có thể được ghép cùng với
mô – đun quản trị dự án)
- T6: Dễ cài đặt = 3
- T7: Dễ sử dụng = 4 (chương trình phải dễ dùng)
- T8: Di động(Portability) = 0 (không cần thiết)
- T9: Tùy biến(changeability) = 2 (không thay đổi quy trình tính toán, có thể thay
đổi các trọng số hay thêm, bớt các yếu tố - dễ thực hiện bằng cách thiết kế khéo
cơ sở dữ liệu)
- T10: Khả năng đồng thời = 0 (không cần thiết)
Chương 5
56
- T11: Các đặc điểm an ninh đặc biệt = 0 (không cần thiết phải xây dựng trong
một chương trình mô phỏng tính toán ở mức độ khóa luận)
- T12: Cung cấp truy cập cho các bên thứ 3 = 0 (không xây dựng)
- T13: Chính sách đào tạo người dùng đặc biêt = 1 (chương trình thực hiện tính
toán theo quy trình UCP cho trước mà không thêm bước thực hiện nào cần phải
tập huấn đặc biệt cho người dùng để biết cách sử dụng)
Xem xét Bảng 5-5, ta có:
totalF = 14
Tính TCF = C1 + C2 * totalF = 0.6 + 0.01 * 14
TCF = 0.74
Chương 5
57
Yếu tố kĩ
thuật
Mô tả yếu tố Trọng số Tỉ lệ dự án Kết quả
T1 Hệ thống phân tán 2 0 0
T2 Các mục tiêu hiệu năng ứng dụng,
về mặt đáp ứng hay thông lượng
1 0 0
T3 Hiệu quả người dùng cuối (trực
tuyến)
1 3 3
T4 Xử lý nội bộ phức tạp 1 1 1
T5 Tính sử dụng lại, mã phải có khả
năng để dùng lại trong các ứng
dụng khác
1 4 4
T6 Dễ cài đặt 0.5 3 1
T7 Dễ sử dụng 0.5 4 2
T8 Di động (portablity) 2 0 0
T9 Tùy biến (Changeability) 1 2 2
T10 Đồng thời 1 0 0
T11 Các đặc điểm an ninh đặc biệt 1 0 0
T12 Cung cấp truy cập trực tiếp cho các
bên thứ 3
1 0 0
T13 Các chính sách đào tạo người dùng
đặc biệt
1 1 1
Yếu tố
tổng cộng
totalF = 14
Bảng 5-5. Cho điểm các Yếu tố kĩ thuật - dự án UCP Estimator
Bước 3: Tính ECF
Đánh tỉ lệ các yếu tố Môi trường của dự án được đưa ra trong Hình 3-7, mục 3.2.1.3.
Việc cho tỉ lệ từ yếu tố E1 đến E5 chính là cho tỉ lệ của chính bản thân em – người viết
khóa luận – người trực tiếp xây dựng chương trình.
Chương 5
58
- E1: Quen thuộc với UML = 4
- E2: Kinh nghiệm ứng dụng = 3
- E3: Kinh nghiệm hướng đối tượng = 4
- E4: Khả năng phân tích = 4
- E5: Động lực = 5
- E6: Các yêu cầu ổn định = 5 ( không thay đổi yêu cầu trong quá trình phát triển)
- E7: Nhân lực bán thời gian = 0
- E8: Ngôn ngữ lập trình khó = 4 (ngôn ngữ PHP với giao diện HTML không hỗ
trợ hoàn toàn kĩ nghệ theo Hướng đối tượng)
Yếu tố kinh
nghiệm
Mô tả yếu tố Trọng số Tỉ lệ dự án Kết quả
E1 Quen thuộc với UML 1.5 4 6
E2 Kinh nghiệm ứng dụng 0.5 3 1.5
E3 Kinh nghiệm hướng đối tượng 1 4 4
E4 Khả năng phân tích 0.5 4 2
E5 Động lực 1 5 5
E6 Các yêu cầu ổn định 2 5 10
E7 Những nhân lực bán thời gian -1 0 0
E8 Ngôn ngữ lập trình khó -1 4 -4
Yếu tố tổng
cộng
totalF = 24.5
Bảng 5-6. Cho điểm các Yếu tố môi trường - dự án UCP Estimator
Dựa vào Bảng 20 ta có:
totalF = 24.5
Tính ECF = C1 + C2 * totalF = 1.4 + (-0.03 * 24.5)
ECF = 0.665
Chương 5
59
Bước 4: Tính số Điểm Ca sử dụng (UCPs)
UCPs = UUCPs * TCF * ECF = 15 * 0.74 * 0.665
UCPs ≈ 6.7 [UCP]
5.1.2.3 Ước lượng nỗ lực
Đếm count theo cách được mô tả trong phần 3.3, được count = 0, dùng tỉ lệ nỗ lực ER
= 20[người – giờ / UCP] ta có nỗ lực tổng cộng của dự án là:
totalEffort = UCPs * ER = 6.7 * 20
totalEffort = 134 [người – giờ]
totalEffort ≈ 3.5 [người – tuần]
Giá trị nỗ lực này là cao so với một chương trình như UCP Estimator. Điều này sẽ
được xem xét trong phần Đánh giá phương pháp Điểm Ca Sử dụng sau đây:
5.2 Đánh giá phương pháp
5.2.1 Đánh giá quy trình tính toán
Trước hết có thể thấy rằng, UCP là phương pháp ước lượng đầu tiên dựa trên tiến trình
nghiệp vụ để đưa ra kết quả. Trong khi đó, FPA chỉ dựa trên số chức năng, COCOMO
dựa trên kích cỡ chương trình.
Đánh giá mức độ hiệu quả của một phương pháp mới có lẽ nên so sánh với các phương
pháp cũ. Phần này sẽ so sánh quy trình tính toán của phương pháp Điểm Ca Sử dụng
UCP với 2 phương pháp truyền thống là Phân tích Điểm Chức năng FPA và Mô hình
Giá cấu thành COCOMO.
Xem xét quy trình tính toán trên các hệ thống được xây dựng theo phương pháp kĩ
nghệ Hướng Đối tượng:
5.2.1.1 So sánh UCP với FPA
Quy trình tính toán của phương pháp ước lượng UCP dựa trên phương pháp FPA, do
đó nó thừa hưởng những ưu điểm của FPA như độc lập về mặt công nghệ và có thể
đưa ra được ước lượng sớm trong vòng đời phát triển dự án, ngay sau khi có bản đặc tả
ca sử dụng của hệ thống.
Hơn thế, UCP khắc phục được nhiều nhược điểm cố hữu của FPA.
Chương 5
60
Thứ nhất, việc đánh giá và cho điểm các Yếu tố Kĩ thuật của hệ thống được xây dựng
là chi tiết hơn nhiều so với FPA khi mà các yếu tố đã được đánh trọng số ảnh hưởng
tổng quát, sau đó đánh giá tỉ lệ phạm vi ảnh hưởng trên dự án, cuối cùng lấy tích để có
điểm ảnh hưởng của yếu tố. Trong khi FPA lấy điểm ảnh hưởng chỉ là điểm tỉ lệ phạm
vi ảnh hưởng trên dự án, có khoảng giá trị cho tất cả các yếu tố từ 0 đến 5.
Thứ hai, các Yếu tố Môi trường ảnh hưởng lên tiến độ dự án đã được đưa vào quy
trình tính toán. Việc đưa các Yếu tố Môi trường vào quy trình tính toán tạo ra khả
năng ánh xạ tuyến tính từ đơn vị Điểm Ca Sử dụng sang [người – giờ], với các giá trị
ER= 20 hay ER= 28 như được nêu ở mục 3.2.2, trong khi FPA không có khả năng này
mà phải tiến hành ước lượng nỗ lực dựa trên một mô hình thuật toán như COCOMO.
Thứ ba, đối với vấn đề sử dụng lại mô – đun trong Kĩ nghệ Hướng Đối tượng, FPA
gặp khó khăn khi đếm số chức năng của các mô – đun thừa kế. Nhưng đối với FPA, vì
dựa trên biểu đồ Ca Sử dụng, là một kí pháp của Kĩ nghệ Hướng Đối tượng, nên dễ
dàng giải quyết vấn đề này với các kĩ thuật > hay >,
>, >.
Thứ tư, FPA đếm số lượng file thao tác logic nội bộ là một bất cập với các hệ cơ sở dữ
liệu hiện đại, thì UCP đã bỏ qua việc đếm này, mà đánh giá số giao dịch ca sử dụng và
có thể cụ thể hơn là đánh giá số lớp phân tích để thi hành ca sử dụng dễ dàng hơn
nhiều.
Thứ năm, FPA chỉ có thể ước lượng cho các ứng dụng nghiệp vụ bình thường, mà
không thể cho các ứng dụng khoa học và công nghệ, khi mà độ phức tạp nằm trong nội
hàm tính toán chứ không phải số lượng chức năng, thì UCP lại giải quyết được vấn đề
này ở số giao dịch ca sử dụng (liên quan tới số bước tính toán).
5.2.1.2 So sánh UCP với COCOMO
UCP và COCOMO có điểm giống nhau là các yếu tố điều chỉnh được xem xét điểm
chi tiết và tính đến cả các yếu tố môi trường có ảnh hưởng đến tiến độ hoàn thành dự
án.
COCOMO là mô hình ước lượng giá cấu thành (nỗ lực và thời gian) dựa trên kích cỡ
theo đơn vị LOC (line of code) của chương trình. Việc đánh giá số dòng lệnh sớm và
đáng tin cậy là khó và phụ thuộc rất nhiều vào ngôn ngữ lập trình. Hơn nữa đánh giá là
không phù hợp khi mã chương trình được sinh ra tự động nhờ các công cụ hiện đại chứ
không phải do con người viết. Còn UCP trước hết đánh giá kích cỡ của chương trình
Chương 5
61
theo đặc tả yêu cầu, rồi sau đó đánh giá nỗ lực theo một ánh xạ tuyến tính. Chỉ cần có
biểu đồ ca sử dụng của đặc tả là có thể đưa ra ước lượng theo UCP.
Đánh giá nỗ lực theo COCOMO có vẻ không hợp lý khi đã đồng nhất lượng tri thức ở
trong một số lượng dòng lệnh giống nhau của các ngôn ngữ khác nhau, như được nêu
trong mục 2.2.3. UCP thì không mắc phải vấn đề này khi đánh giá nỗ lực trực tiếp trên
lượng tri thức chứa trong số Điểm Ca Sử dụng. Nỗ lực thay đổi theo ngôn ngữ đã được
UCP đưa vào yếu tố môi trường Độ khó ngôn ngữ lập trình.
Khi đánh giá nỗ lực theo COCOMO, phải xác định một trong ba phương thức phát
triển dự án để lấy các hệ số tính toán. Việc xác định này dựa nhiều vào chủ quan và có
thể gây nhầm lẫn. Trong khi đó, các hệ số của UCP là rõ ràng và không cần phải lựa
chọn.
5.2.2 Đánh giá trên thực tế
Xem xét việc áp dụng ước lượng trong Bài toán 2 ở phần trên có thể thấy rằng kết quả
ước lượng nỗ lực cuối cùng 3.5[người – tuần] là khá cao so với một chương trình như
UCP Estimator. Trong khi đó Yếu tố Môi trường ECF có giá trị 0.665 đã làm giảm
đáng kể số UCPs. Nếu chỉ tính riêng kích cỡ kĩ thuật mà không xét đến các yếu tố môi
trường thì
UCPs = UUCPs * TCF = 15 * 0.74 ≈ 11 [UCP]
Nếu chọn ER (tỉ lệ nỗ lực) = 20 [người – giờ] / UCP thì ước lượng nỗ lưc là:
totalEffort = 11 * 20 = 220 [người – giờ] = 5.5 [người – tuần]
Nếu chọn ER = 28 [người – giờ] / UCP thì kết quả còn cao hơn.
Kết quả cao này là do việc cho điểm các Ca sử dụng và Tác nhân trong dự án này là
cao hơn so với thực tế, dẫn đến UUCPs trội hơn.
Việc cho điểm Ca sử dụng dựa vào phép đếm số giao dịch nhưng trong trường hợp này
điểm của một giao dịch không cao như trọng số theo kinh nghiệm của phương pháp.
Như vậy khi cho điểm Ca sử dụng cần thiết phải xét đến độ phức tạp của giao dịch.
Thêm một vấn đề nữa, khi số giao dịch của ca sử dụng rất lớn thì nảy sinh vấn đề trong
xác định loại ca sử dụng. Thí dụ, một ca sử dụng có 8 giao dịch và một ca sử dụng có
30 giao dịch đều được xếp vào loại Phức tạp với cùng trọng số.
Với việc cho điểm tác nhân thì cũng có những vấn đề tương tự, nhưng vì trọng số của
mỗi loại tác nhân là nhỏ nên không ảnh hưởng nhiều đến kết quả ước lượng.
Chương 5
62
5.2.3 Kết luận
Điểm Ca Sử dụng có tiềm năng để đưa ra những kết quả tin cậy bởi vì những ước
lượng của nó được đưa ra từ các tiến trình nghiệp vụ trên thực tế, các ca sử dụng – của
một hệ thống. Thêm nữa, quy trình tính toán của phương pháp Điểm Ca Sử dụng khắc
phục được hầu hết các điểm yếu của những phương pháp truyền thống trong thực tế kĩ
nghệ hiện nay. Tuy vậy, nhưng vì phương pháp còn chưa được hiệu chỉnh nhiều trong
thực tế nên khi áp dụng cần phải chú ý một số khía cạnh:
- Số lượng các bước trong một kịch bản ảnh hưởng đến ước lượng. Một số lượng
lớn các bước trong một kịch bản ca sử dụng sẽ làm cho kết quả theo hướng
phức tạp và gia tăng Điểm Ca Sử dụng. Một số lượng nhỏ các bước sẽ làm cho
nó theo hướng đơn giản. Đôi khi, các nhóm của các bước có thể được giảm đến
một số lượng ít hơn mà không ảnh hưởng đến tiến trình nghiệp vụ. Từ đó, giữ
các ca sử dụng ở mức độ phức tạp hợp lý. Một giao dịch quá đơn giản có thể
không cần đếm, ([2] Collasris, 2009). Khi có nhiều giao dịch trong một ca sử
dụng có thể xem xét việc tách ca sử dụng. Theo kinh nghiệm áp dụng được nêu
trong ([2] Collasris, 2009), khi một ca sử dụng có nhiều hơn 12 giao dịch, thì
thường ca sử dụng đó hoạt động cho nhiều hơn 2 mục đích, có thể xem xét việc
tách ca sử dụng để đếm như những ca sử dụng riêng lẻ. Áp dụng điểm mạnh
của các kĩ thuật >, >, tổng quát hóa(generalization), thừa
kế, giao diện, hiện thực hóa(realization) để điều chỉnh độ đến mức độ thích hợ
độ phức tạp của các ca sử dụng.
- Số lượng các tác nhân trong một ca sử dụng cũng ảnh hưởng đến ước lượng.
Xem xét các tác nhân để áp dụng các kĩ thuật tổng quát hóa, thừa kế, giao diện,
hiện thực hóa cho phù hợp.
- Các Yếu tố điều chỉnh (Kĩ thuật và Môi trường) cần được điều chỉnh theo thời
gian để phù hợp với thực tế
- Yếu tố Năng suất cũng cần được điều chỉnh cho hợp lý.
5.3 Đề xuất hướng phát triển
5.3.1 Phát triển lý thuyết chương trình
Chương 5
63
Quy trình tính toán của phương pháp là tốt nhưng những hệ số trọng số của các thành
phần thì chưa phản ánh được đúng bản chất. Chúng được đưa ra nhờ đánh giá thống kê
từ một số dự án mà chưa được kiểm nghiệm trên phạm vi rộng lớn. Khi áp dụng
phương pháp cần tiến hành thống kê số liệu để phân tích và hiệu chỉnh các hệ số cho
phù hợp. Một chu trình cải tiến tiến trình tính toán được đưa ra bởi ([1] Carroll, 2005)
như Hình 5-1.
5.3.2 Phát triển chương trình tính toán UCP Estimator
Chương trình UCP Estimator tính toán ước lượng trên mô – đun riêng lẻ. Để hỗ trọ tốt
hơn cho việc quản trị dự án, chương trình UCP Estimator có thể kết hợp với một
chương trình quản trị dự án. Khi đó, chương trình UCP Estimator sẽ nhận các thông
tin phân tích từ chương trình quản trị để tính toán rồi trả về các ước lượng cho chương
trình quản trị.
Định nghĩa
tiến trình
Phân tích và cải
thiện tiến trình
Thực thi tiến
trình
Thu thập
các số liệu
Thí điểm / mở rộng
Dùng các công cụ
Điều khiển tiến
trình thống kê
Cơ sở dữ liệu
tiến trình
Hình 5-1. Chu trình cải tiến tiến trình UCP. Nguồn tham khảo: ([5] Carroll E. R. , 2005)
Phụ lục A – Khóa luận tốt nghiệp – Nguyễn Trần Việt
64
PHỤ LỤC A.
DỰ ÁN XÂY DỰNG MÔ – ĐUN ATM
Phát biểu bài toán
Xây dựng mô – đun hoạt động trên máy ATM có 2 chức năng Rút tiền và Chuyển tiền.
Các module cần thiết khác coi như đã có sẵn.
Biểu đồ ca sử dụng của dự án
Hình 5. Biểu đồ ca sử dụng tổng thể - xây dựng mô-đun ATM
Kịch bản ca sử dụng “Định danh”:
Tác nhân
Khách hàng
Hệ thống
Luồng sự kiện 1. Đưa thẻ vào máy ATM 2. Yêu cầu nhập mã PIN
3. Nhập PIN 4. Xác nhận
Ngoại lệ 1. Nếu xác nhận nhập mã PIN sai tại bước 4, quay lại bước
2.
2. Nếu nhập mã PIN sai 3 lần, máy ATM giữ lại thẻ ATM
Bảng 11. Kịch bản ca sử dụng “Định danh” - ATM
Kịch bản ca sử dụng rút tiền:
Phụ lục A
65
Tác nhân
Khách hàng
Hệ thống
Luồng sự kiện 5. Chọn chức năng rút tiền 6. Yêu cầu nhập số tiền cần rút
7. Nhập số tiền rút 8. Xác nhận
9. Trả tiền
Ngoại lệ 1. Nếu xác nhận thấy số tiền rút được nhập không hợp lệ tại
bước 4, thì thông báo lỗi và quay lại bước 2
Bảng 2. Kịch bản ca sử dụng “Rút tiền” - ATM
Kịch bản ca sử dụng “Chuyển tiền”:
Tác nhân
Khách hàng
Hệ thống
Luồng sự kiện 13. Chọn chức năng Chuyển
tiền
14. Yêu cầu nhập số tiền cần
chuyển
15. Nhập số tiền chuyển 16. Xác nhận số tiền
17. Yêu c
Các file đính kèm theo tài liệu này:
- LUẬN VĂN-NGHIÊN CỨU ƯỚC LƯỢNG DỰ ÁN.pdf