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 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 * 65
1/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,
n
i, j
* W
i, 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
n
i, j
: là số lượng thành phần thuộc loại i có độ phức tạp j
W
i, 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 = C
1
+ C
2



14
1i
F
i

trong đó:
Chương 2
14

TCF là Yếu tố Độ phức tạp Kĩ thuật
C
1
= 0.65
C
2

= 0.01
F
i
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
F
i
là mức độ ảnh hưởng tổng cộng (total Degree of
Influence) của 14 yếu tố, do đó công thức trên có thể viết lại thành:
TCF = C
1
+ C
2
* DI
Bước 3: Tính toán cuối cùng
Kích cỡ xử lý thông tin của một hệ thống theo số lượng Điểm Chức năng (FPs) được
tính theo công thức:
FPs = UFPs * TCF
Trong đó:
FPs : số điểm chức năng của hệ thống
UFPs : số điểm chức năng chưa được điều chỉnh được tính từ bước 1
TCF : yếu tố độ phức tạp kĩ thuật được tính từ bước 2
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