Xây dựng công cụ ước lượng chi phí phát triển phần mềm dựa trên CBR và thử nghiệm ở Công ty Honda Việt Nam

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ





LƢƠNG MINH HẢI

XÂY DỰNG CÔNG CỤ ƢỚC LƢỢNG CHI PHÍ
PHÁT TRIỂN PHẦN MỀM DỰA TRÊN CBR VÀ
THỬ NGHIỆM Ở CÔNG TY HONDA VIETNAM





LUẬN VĂN THẠC SĨ












HÀ NỘI - 2010

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ





LƢƠNG MINH HẢI

XÂY DỰNG CÔNG CỤ ƢỚC LƢỢNG CHI PHÍ
PHÁT TRIỂN PHẦN MỀM DỰA TRÊN CBR VÀ
THỬ NGHIỆM Ở CÔNG TY HONDA VIETNAM

Ngành: CÔNG NGHỆ THÔNG TIN
Chuyên ngành: CÔNG NGHỆ PHẦN MỀM
Mã số: 60 48 10



LUẬN VĂN THẠC SĨ



Người hướng dẫn khoa học
TS. Trƣơng Anh Hoàng






HÀ NỘI - 2010

MỤC LỤC


CHƢƠNG 1 – GIỚI THIỆU 1
CHƢƠNG 2 – QUY TRÌNH ƢỚC LƢỢNG CHI PHÍ PHÁT TRIỂN PHẦN MỀM 4

2.1. Tổng quan và mục đích ước lượng 4
2.2. Chi tiết quy trình ước lượng 4
2.2.1. Xác định phạm vi và mục tiêu của dự án 6
2.2.2. Xác định phạm vi kĩ thuật và các giả định 6
2.2.3. Thu thập dữ liệu 6
2.2.4. Xác định kích cỡ phần mềm 7
2.2.5. Chuẩn bị đường mức ước lượng 7
2.2.6. Thẩm định và phân tích các rủi ro 9
2.2.7. Kiểm định kết quả ước lượng 9
2.2.8. Xây dựng kế hoạch thực thi dự án 10
2.2.9. Xây dựng tài liệu cho quá trình ước lượng 10
2.2.10. Đánh giá dự án thông qua quá trình phát triển 11
2.3. Một số phương pháp ước lượng chi phí phát triển phần mềm 11
2.3.1. Mô hình COCOMO 11
2.3.2. Mô hình điểm chức năng (Function Point) 15
2.3.3. Phương pháp chuyên gia 16
CHƢƠNG 3 – PHƢƠNG PHÁP LẬP LUẬN DỰA TRÊN KINH NGHIỆM 19
3.1. Giới thiệu chung 19
3.2. Chi tiết phương pháp lập luận dựa trên kinh nghiệm 19
3.2.1. Tìm kiếm dữ liệu tương tự 22
3.2.2. Sử dụng lại kết quả tìm kiếm 24
3.2.3. Bảo trì cơ sở dữ liệu các ca lập luận 27
3.3. Ưu và nhược điểm của phương pháp CBR. 30
3.3.1. Ưu điểm 30
3.3.2. Nhược điểm 30
CHƢƠNG 4: PHÂN TÍCH THIẾT KẾ HỆ THỐNG PC-PACK-CES 32
4.1. Thiết kế hệ thống 32
4.2. Mô hình triển khai 32
4.3. Phân tích kiến trúc hệ thống 33
4.3.1. Phân tích yêu cầu 33

4.3.2. Xác định các gói phân tích 34
4.3.3. Xác định tác nhân 35
4.3.4. Biểu ca ca sử dụng 35
4.3.5. Luồng sự kiện 36
4.4. Phân tích ca sử dụng 40
4.4.1. Đăng nhập vào hệ thống 40
4.4.2. Ca sử dụng quản lý danh mục dự án 42
4.4.3. Khai báo yếu tố chi phí 45
4.4.4. Ca sử dụng ước lượng chi phí 48
4.5. Thiết kế cơ sở dữ liệu PC-PACK-CES 50
4.5.1. Sơ đồ logic quan hệ các bảng dữ liệu 50
4.5.2. Mô tả chi tiết các bảng dữ liệu 51
CHƢƠNG 5: ĐÁNH GIÁ KHẢ NĂNG ÁP DỤNG PC-PACK-CES TẠI CÔNG TY
HONDA 56
5.1. Giới thiệu các hệ thống phần mềm tại công ty Honda 56
5.2. Quy trình thử nghiệm phần mềm PC-PACK-CES tại công ty Honda 58
5.2.1. Thu thập, phân tích và xử lý dữ liệu 58
5.2.2. Kết quả thử nghiệm chương trình 61
5.3. Đánh giá khả năng áp dụng phần mềm PC-PACK-CES tại công ty Honda 64
KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN CỦA ĐỀ TÀI 65
TÀI LIỆU THAM KHẢO 66

BẢNG KÝ HIỆU CÁC TỪ VIẾT TẮT



Viết tắt
Thuật ngữ

Giải thích
CBR
Case based reasoning
Phương pháp lập luận dựa trên
kinh nghiệm
KNN
K nearest Neighbor
Thuật toán tìm k người hàng xóm
gần nhất
PC-PACK-CES

Phần mềm ước lượng chi phí phát
triển phần mềm tại công ty Honda

4.3. DANH MỤC HÌNH VẼ


Hình 2 - 1. Quy trình ước lượng chi phí phát triển dự án phần mềm[5] 5
Hình 3 - 1. Mô hình lập luận dựa trên kinh nghiệm [5]. 20
Hình 3 - 2. Sơ đồ phân rã công việc hệ thống CBR[7] 21
Hình 3 - 3. Sơ đồ mô tả quy trình tìm kiếm CBR[7] 23
Hình 3 - 4. Sơ đồ mô tả quá trình hiệu chỉnh giải pháp 26
Hình 3 - 5. Mô tả phạm vi và khả năng tìm ra lời giải của ca lập luận. 29
Hình 4 - 1. Thiết kế tổng quan hệ thống 32
Hình 4 - 2. Mô hình triển khai PC-PACK-CES 33
Hình 4 - 3. Sơ đồ các gói chức năng của hệ thống 34
Hình 4 - 4. Mô hình ca sử dụng mức gộp của hệ thống. 36
Hình 4 - 5. Biểu đồ phân tích lớp đăng nhập hệ thống. 40
Hình 4 - 6. Biểu đồ tuần tự phân tích thực thi ca sử dụng đăng nhập hệ thống 40
Hình 4 - 7. Biểu đồ hoạt động chức năng đăng nhập hệ thống. 41
Hình 4 - 8. Màn hình đăng nhập hệ thống PC-PACK-CES 41
Hình 4 - 9. Màn hình chính hệ thống PC-PACK-CES 42
Hình 4 - 10. Biểu đồ lớp phân tích thực thi ca sử dụng khai báo dự án cơ sở lập luận 42
Hình 4 - 11. Biểu đồ tuần tự phân tích thực thi ca sử dụng quản lý danh mục dự án 43
Hình 4 - 12. Biểu đồ hoạt động ca sử dụng quản lý dự án cơ sở lập luận 43
Hình 4 - 13. Màn hình quản lý thông tin dự án cơ sở lập luận. 44
Hình 4 - 14. Màn hình khai báo thông tin của dự án mới. 44
Hình 4 - 15. Màn hình sửa thông tin dự án 45
Hình 4 - 16. Biểu đồ lớp phân tích thực thi ca sử dụng khai báo yếu tố chi phí 45
Hình 4 - 17. Biểu đồ tuần tự phân tích thực thi ca sử dụng khai báo yếu tố chi phí 46
Hình 4 - 18. Biểu đồ hoạt động ca sử dụng quản lý yếu tố chi phí 46
Hình 4 - 19. Màn hình quản lý danh mục yếu tố chi phí 47
Hình 4 - 20. Màn hình khai báo yếu tố chi phí mới. 47
Hình 4 - 21. Màn hình sửa dữ liệu yếu tố chi phí. 48

Hình 4 - 22. Biểu đồ phân tích lớp thực thi ca sử dụng ước lượng chi phí 48
Hình 4 - 23. Biểu đồ tuần tự phân tích thực thi ca sử dụng ước lượng chi phí 49
Hình 4 - 24. Biểu đồ hoạt động ca sử dụng ước lượng chi phí 49
Hình 4 - 25. Màn hình ước lượng chi phí phát triển dự án 50
Hình 4 - 26. Quan hệ các bảng dữ liệu 50
Hình 5 - 1. Cơ cấu tổ chức công ty Honda 56
Hình 5 - 2. Kết quả ước lượng bằng phương pháp khoảng cách Euclidean. 63
Hình 5 - 3. Kết quả ước lượng bằng phương pháp tính độ tương tự thuộc tính 63
4.3.


DANH MỤC BẢNG


Bảng 2 - 1. Bảng hằng số dùng trong tính toán bằng phương pháp COCOMO cơ bản 12
Bảng 2 - 2. Thang điểm đánh giá các đặc trưng của dự án 14
Bảng 2 - 3. Bảng hệ số tính bằng phương pháp COCOMO trung gian 15
Bảng 2 - 4. Bảng quy đổi số dòng lệnh trong một chức năng của các ngôn ngữ lập trình
15
Bảng 5 - 1. Danh sách các hệ thống phần mềm sử dụng tại Honda 57
Bảng 5 - 2. Đặc trưng thuộc tính của các dự án đã thực hiện thành công 59
Bảng 5 - 3. Danh sách các dự án lưu trong CSDL dùng để lập luận 61
Bảng 5 - 4. Dữ liệu đầu vào của dự án cần ước lượng 62
Bảng 5 - 5. Chi phí dự toán của dự án mới 62
Bảng 5 - 6. Bảng kết quả thử nghiệm ước lượng bằng PC-PACK-CES 64

1
CHƢƠNG 1 – GIỚI THIỆU

1.1. Đặt vấn đề
Sự thành công hay thất bại của một dự án nói chung và dự án phát triển phần
mềm nói riêng phụ thuộc rất nhiều vào những kết quả của quá trình ước lượng, lập dự
toán chi phí trước thời điểm triển khai dự án vào thực tế. Chủ đề này đã thu hút sự chú
của rất nhiều nhà khoa học trên thế giới và đến nay đã có những công trình nghiên cứu
có chất lượng.
Từ xu hướng đó tác giả đã nghiên cứu một số phương pháp luận thường được
sử dụng để ước lượng chi phí phát triển phần mềm, đặc biệt là những phương pháp mô
phỏng quá trình lập luận của con người. Trong số đó, phương pháp lập luận dựa trên
kinh nghiệm CBR (Case based reasoning) là một trong những phương pháp có nhiều
ưu điểm, có khả năng áp dụng thành công vào công việc ước lượng chi phí. Đã có
nhiều sản phẩm phần mềm thực hiện ước lượng bằng phương pháp này, tuy nhiên
chưa có tiêu chuẩn cụ thể để đánh giá độ tin cậy kết quả mà những sản phẩm này đưa
ra. Vì vậy qua luận văn này tác giả mong muốn:
- Tìm hiểu phương pháp ước lượng dựa trên kinh nghiệm CBR (Case based
reasoning).
- Xây dựng một công cụ ước lượng chi phí phát triển phần mềm sử dụng kiến
thức đã tìm hiểu được.
- Thực nghiệm và đánh giá phương pháp ước lượng chi phí phát triển phần
mềm tại phòng Hệ thống - Công ty Honda Vietnam.
1.2. Tính cấp thiết của đề tài
Trong quá trình phát triển dự án phần mềm thì quản lý chi phí là một công việc
có tầm quan trọng vô cùng lớn, bao gồm những quy trình đảm bảo cho dự án được
hoàn tất trong sự cho phép của ngân sách: lập kế hoạch cho nguồn tài nguyên, ước
lượng chi phí, dự toán chi phí, kiểm soát và điều chính chi phí. Nếu công việc này
không được làm tốt sẽ dẫn tới sự thất bại của dự án và theo số liệu thống kê tại các
doanh nghiệp Mỹ do CHAOS thực hiện thì chi phí trung bình vượt quá dự toán ban
đầu theo nghiên cứu từ năm 1995 là 189% và giảm xuống còn 145% trong năm 2001.
Hậu quả của việc huỷ các dự án Công nghệ thông tin ở Mĩ đã làm tốn trên 81 tỉ đô la

(số liệu thống kê năm 1995 do CHAOS thực hiện)[5]. Vì vậy, việc ước lượng chính
xác chi phí cần thiết để xây dựng các phần mềm là một vấn đề đang được quan tâm
hiện nay.
Xuất phát từ nhu cầu trên, tính từ năm 1960 cho đến nay đã có nhiều nhà khoa
học đã tiến hành những công trình nghiên cứu nhằm tìm ra phương pháp luận chính
xác nhất để ước lượng chi phí phát triển phần mềm như: mô hình ước lượng bằng tham
số của Frank Freiman (1970)[7], phương pháp ước tính dựa trên các thông số
COCOMO (1977) và COCOMO II (1990) của Barry W. Boehm[7], phương pháp ước

2
tính bằng điểm chức năng của Capres Jones (1980)[7]. Tuy nhiên, những phương pháp
này còn tồn tại nhiều hạn chế như yêu cầu phải có đủ số thông tin đầu vào để tính toán
chính xác, dựa trên một mô hình tính toán được xác định rõ nên khó áp dụng được ở
những giai đoạn đầu của quá trình phát triển dự án. Để khắc phục những khó khăn đó,
Roger Schank và các đồng nghiệp tại đại học Yale đề xuất ước lượng chi phí bằng
phương pháp lập luận dựa trên kinh nghiệm CBR (Case base reasoning) năm 1977[4].
Ưu điểm nổi trội của phương pháp này là mô phỏng quá trình lập luận của con người
nên dễ hiểu và có thể làm công cụ giải trình hiệu quả cho các thành viên tham gia phát
triển dự án phần mềm. Ngoài ra, phương pháp cho phép thực hiện ước lượng với tập
nhỏ dữ liệu ban đầu, dữ liệu trong tập kinh nghiệm sẽ được cập nhật ở những lần thực
hiện ước lượng tiếp theo nên độ chính xác của kết quả ước lượng sẽ tỉ lệ thuận với số
lượng dự án được lưu trữ trong cơ sở dữ liệu.
1.3. Mục tiêu của đề tài
Mục tiêu của luận văn này nhằm tập trung nghiên cứu về phương pháp ước
lượng dựa trên kinh nghiệm qua đó xây dựng một công cụ áp dụng kiến thức đã tìm
hiểu được và đánh giá khả năng áp dụng sản phẩm tại phòng Hệ thống – Công ty
Honda Vietnam.
1.4. Đối tƣợng và phạm vi nghiên cứu
- Đối tượng: các dự án phần mềm được phát triển tại công ty Honda Vietnam
từ năm 2006 đến nay.

- Phạm vi: bài toán ước lượng chi phí phát triển phần mềm tại phòng Hệ
thống, công ty Honda Vietnam.
1.5. Kết cấu của luận văn
Bố cục của luận văn chia thành 05 chương:
- Chƣơng 1: Giới thiệu.
Nội dung chương: Nêu tính cấp thiết của đề tài, mục tiêu và phạm vi nghiên
cứu của luận văn.
- Chƣơng 2: Quy trình ước lượng chi phí phát triển phần mềm
Nội dung chương: Mô tả chi tiết các bước của quy trình ước lượng chi phí
phát triển phần mềm và một số phương pháp ước lượng thường sử dụng.
- Chƣơng 3: Phương pháp lập luận dựa trên kinh nghiệm.
Nội dung chương: Trình bày các bước thực hiện và đánh giá ưu nhược điểm
của phương pháp lập luận dựa trên kinh nghiệm.
- Chƣơng 4: Phân tích thiết kế hệ thống PC-PACK-CES.
Nội dung chương: Trình bày chi tiết phân tích, thiết kế của hệ thống PC-
PACK-CES (ca sử dụng, biểu đồ tuần tự, thiết kế bảng dữ liệu).
- Chƣơng 5: Đánh giá khả năng áp dụng PC-PACK-CES tại công ty Honda
Vietnam.
Nội dung chương: Trình bày kết quả thử nghiệm và đánh giá khả năng áp
dụng hệ thống PC-PACK-CES tại công ty Honda.

3
- Kết luận và hƣớng phát triển của đề tài.
Nội dung chương: Trình bày những kết luận của tác giả sau khi nghiên cứu
và triển khai phần mềm áp dụng phương pháp lập luận dựa trên kinh nghiệm
tại công ty Honda. Ngoài ra, tác giả cũng đề xuất hướng nghiên cứu và cải
tiến chương trình của tác giả trong thời gian tới.




4
CHƢƠNG 2 – QUY TRÌNH ƢỚC LƢỢNG CHI PHÍ
PHÁT TRIỂN PHẦN MỀM

2.1. Tổng quan và mục đích ƣớc lƣợng
Phần mềm là một sản phẩm đặc thù có quan hệ mật thiết với nguồn ngân sách
đầu tư xây dựng hệ thống thông tin của bất kì tổ chức nào. Với tính đa dạng của các
đặc trưng phần mềm và sự xuất hiện ngày càng nhiều của các công nghệ mới đã dẫn
đến sẽ ngày càng khó khăn hơn để ước lượng chính xác chi phí cần thiết để phát triển
dự án phần mềm.
Quá trình ước lượng bao gồm việc xác định và thẩm định những yếu tố có liên
quan đến quá trình xây dựng một sản phẩm phần mềm. Đó có thể là những tiến trình
phát triển dự án, nguồn nhân lực và tài nguyên cần để xây dựng và hoàn thiện dự án.
Đến thời điểm hiện tại, việc ước tính chính xác chi phí cần thiết để hoàn thành một dự
án vẫn là một vấn đề được nhiều nhà nghiên cứu trên thế giới quan tâm.
Mục đích của việc ước lượng chi phí phát triển phần nhằm đáp ứng các yêu cầu
sau:
- Là cơ sở để xem xét và đánh giá tính khả thi của dự án: bất kì tổ chức nào
trước khi quyết định có thực hiện dự án hay không sẽ cần tới kết quả ước lượng chi phí
và nguồn tài nguyên cần để hoàn thành dự án. Dựa trên kết quả ước lượng này các tổ
chức sẽ xem xét và đánh giá khả năng của mình có thể thực hiện dự án hay không để
từ đó đưa ra quyết định cần thiết.
- Là công cụ hỗ trợ quản lý dự án: người quản lý dự án sẽ chịu trách nhiệm lập
kế hoạch và điều hành việc thực thi dự án. Nhờ có sự trợ giúp của các kết quả ước
lượng dự án, công việc này sẽ đơn giản và hiệu quả hơn vì công việc quản lý có thể
dựa trên lịch biểu và nguồn nhân lực đã được ước tính trước đó.
- Các thành viên của đội thực hiện dự án sẽ kết hợp với nhau hiệu quả hơn nếu
hiểu rõ vai trò của mình và toàn bộ các hoạt động trong dự án. Điều này có thể đạt
được nếu kết quả ước lượng được áp dụng để xây dựng bảng phân chia nhiệm vụ cho
các thành viên trong nhóm phát triển phần mềm.
Quá trình ước lượng chi phí có thể được thực hiện nhiều lần trong suốt vòng đời
phát triển dự án. Lý do là vì trong quá trình xây dựng hệ thống sẽ xuất hiện ngày càng
nhiều thông tin hữu ích chưa có tại thời điểm thực hiện ước lượng trước đó và những

thông tin này sẽ làm tăng độ chính xác, chi tiết của quá trình ước lượng.
2.2. Chi tiết quy trình ƣớc lƣợng
Nếu quá trình ước lượng chi phí được tích hợp với quá trình phát triển phần
mềm thì có thể lập nên các kế hoạch dự án khả thi và đáng tin cậy, giúp thoả mãn các
yêu cầu của hệ thống và các cam kết đã đề ra. Ngoài ra, quá trình này còn hỗ trợ đắc
lực cho hoạt động quản lý dưới hình thức cung cấp những thông tin kế hoạch chính
xác và kịp thời.

5
Cấu trúc của dự án được hình thành từ nhiều yếu tố khác nhau bao gồm đặc tả
yêu cầu và kiến trúc của hệ thống, yêu cầu chất lượng, kế hoạch sử dụng nguồn nhân
lực. Tuy nhiên, yếu tố có vai trò quan trọng nhất và có vai trò quyết định tới sự thành
công hoặc thất bại của dự án là việc ước lượng phạm vi, yếu tố thời gian và chi phí cần
thiết để hoàn thành dự án. Quá trình ước lượng có thể tác động tới nhiều khía cạnh của
dự án, ràng buộc các hoạt động có thể được thực hiện trong quá trình phát triển hoặc
nâng cấp sản phẩm phần mềm và là cơ sở để lựa chọn những phương án đã lập kế
hoạch.
Từ những phân tích trên, chúng ta có thể định nghĩa ước lượng là quá trình đưa
ra nhận định về giá trị xấp xỉ, gần đúng của một số thông tin mà ta quan tâm. Ước
lượng có thể dựa trên miền tri thức hoặc giả định không đầy đủ hay hoàn chỉnh. Đã có
nhiều công trình nghiên cứu để chuẩn hoá quy trình ước lượng chi phí phát triển phần
mềm, tuy nhiên cho đến nay vẫn chưa có một mô hình tiêu chuẩn được thừa nhận và
sử dụng rộng rãi. Mỗi một tổ chức sẽ có một mô hình ước tính chi phí của riêng mình,
nhưng nhìn chung những mô hình đó bao gồm những bước chính sau:

Hình 2 - 1. Quy trình ước lượng chi phí phát triển dự án phần mềm[5]

6
2.2.1. Xác định phạm vi và mục tiêu của dự án
Những yêu cầu ở thời điểm bắt đầu thực hiện dự án cần định nghĩa và lập tài

liệu với nội dung thể hiện những mong muốn vào kết quả ước lượng. Nếu tất cả các
thành viên tham gia dự án có thể hiểu rõ phạm vi và mục tiêu của quá trình ước lượng
thì sẽ hình thành đường mức cơ sở và có thể dựa vào đó để đánh giá tác động của
những thay đổi của dự án trong tương lai. Ngoài ra, công việc này còn giúp các thành
viên của dự án có thể thấy được những hiểu lầm và làm sáng tỏ các giả định trái ngược
nhau về những gì được mong đợi của các nhóm tham gia dự án.
Bằng việc lập tài liệu đặc tả ứng dụng bao gồm các chi tiết mang tính kĩ thuật,
các mối phụ thuộc bên ngoài dự án và các yêu cầu nghiệp vụ sẽ cung cấp thông tin đầu
vào có giá trị để ước lượng nguồn tài nguyên cần thiết để hoàn thành dự án. Trong đó,
những đặc tính mang tính chất kĩ thuật nếu càng được mô tả chi tiết sẽ càng có giá trị.
Sau khi các yêu cầu đã được làm rõ thì lúc đó mới có thể xác định chi phí khả thi của
dự án.
Quá trình ước lượng cần được cập nhật thường xuyên trong suốt vòng đời phát
triển dự án. Để đảm bảo tính toàn vẹn của dự án, khi có bất kì sự thay đổi nào của dữ
liệu hoặc sự xuất hiện của những thông tin hữu ích thì cần phải lưu trữ lại và sẽ là một
yếu tố tham gia quá trình ước lượng.
2.2.2. Xác định phạm vi kĩ thuật và các giả định
Chúng ta cần xác định rõ các chức năng có trong quá trình ước lượng để thiếp
lập đường mức kĩ thuật hợp lý. Trong trường hợp không xác định được các yếu tố
chức năng của ước lượng thì các quy luật nền tảng và các giả định cần nêu rõ những gì
có và không có trong quá trình ước lượng. Những vấn đề liên quan đến sử dụng lại và
những giả định khác cũng cần lập tài liệu để theo dõi.
Mặc dù các quy luật nền tảng và các giả định là cơ sở của quá trình ước lượng
nhưng chúng ta phải nhận thức rằng các quy luật và giả định này chưa hoàn thiện và
còn chứa đựng nhiều yếu tố không chắc chắn ở giai đoạn đầu của ước lượng. Do đó,
cùng với việc thường xuyên thực hiện ước lượng lại cũng cần phải tiến hành xem xét
và định nghĩa lại các giả định trong dự án.
2.2.3. Thu thập dữ liệu
Theo định nghĩa thì bất kì quá trình ước lượng nào cũng bao gồm những yếu tố
không chắc chắn nên chúng ta thường biểu diễn những yếu tố đầu vào dưới dạng

khoảng giá trị thay vì những dữ liệu cụ thể. Điều này sẽ giúp chúng ta có thể thực hiện
quá trình ước lượng ngay cả khi chưa xác định đầy đủ phạm vi của hệ thống đang lập
dự toán.
Tuy nhiên, để đạt được kết quả ước lượng nhất quán đòi hỏi chúng ta phải xác
định được những thông tin cốt lõi. Dữ liệu có liên quan đến dự án không chỉ đến từ
một nguồn duy nhất và cũng không xuất hiện tại cùng một thời điểm nên nếu chúng ta
sử dụng một mẫu biểu tập hợp dữ liệu hoàn chỉnh sẽ có tác dụng tích cực cho công

7
việc thu thập dữ liệu vì khi tìm ra thông tin mới, có giá trị thì đã có sẵn một hình thức
tổ chức và quản lý dữ liệu của toàn bộ dự án.
2.2.4. Xác định kích cỡ phần mềm
Trong điều kiện tối ưu các tổ chức nên thực hiện toàn bộ những bước thuộc quy
trình ước lượng chi phí phát triển phần mềm đã mô tả ở hình 2-2 để có thể đạt được
kết quả ước lượng chính xác và đáng tin cậy. Tuy nhiên, nếu yếu tố thời gian không
cho phép thì nên tập trung vào bước xác định kích cỡ phần mềm. Bằng việc sử dụng
những công cụ tự động ước tính chi phí và lịch biểu thời gian có thể cung cấp dữ liệu
cho những người chịu trách nhiệm phân tích dự án.
Kích cỡ phần mềm là yếu tố có ảnh hưởng rất lớn tới việc xác định chi phí và
lịch biểu thời gian phát triển dự án. Phạm vi của dự án phần mềm được định nghĩa bởi
việc xác định không chỉ những thông tin liên quan đến dự án được phát triển mới mà
còn bao gồm dữ liệu của những hệ thống đã có sẽ được tích hợp vào hệ thống mới.
Ngoài ra, để ước lượng kích cỡ phần mềm chúng ta cần xác định những yếu tố như số
dòng lệnh (SLOC – Source lines of code), số điểm chức năng hoặc bất kì cách tính
đơn vị chương trình nào đang được sử dụng để thống kê. Thông thường, để có thể đưa
ra thông tin tổng thể kích cỡ phần mềm, kết quả ước lượng kích cỡ được biểu diễn
dưới dạng phạm vi chặn trên và chặn dưới. Danh sách bên dưới là một số hình thức
ước lượng kích cỡ phần mềm thường được các tổ chức sử dụng:
 Ý kiến đánh giá của các chuyên gia: là hình thức ước tính dựa trên thông
tin tập hợp lại của các dự án đã thực hiện trước đó và những giả định có thể

diễn ra với hệ thống mới kết hợp với kinh nghiệm của các chuyên gia thuộc
lĩnh vực.
 Hình thức suy luận: là phương pháp so sánh độ tương đồng giữa hai thực
thể dựa trên một số đặc trưng nhất định. Kết quả so sánh ở dạng giá trị xấp
xỉ nên có thể hiệu chỉnh các đặc trưng so sánh với thực thể tương đồng tìm
được để tăng độ chính xác của phương pháp.
 Phương pháp hình thức hoá: là phương pháp thống kê có sử dụng các công
cụ tự động hoặc các thuật toán được xác định trước như hình thức đếm số
lượng các hệ thống con hoặc các lớp con và chuyển đổi thành các điểm chức
năng.
 Phương pháp thống kê định cỡ: là phương pháp cung cấp phạm vi kĩch cỡ
dưới dạng khoảng giới hạn cận trên và cận dưới.
2.2.5. Chuẩn bị đƣờng mức ƣớc lƣợng
Kết quả của quá trình ước lượng có vai trò quyết định tới độ chính xác của ngân
sách và lịch biểu thời gian phát triển dự án. Do đó, để đảm bảo tính chính xác và hiệu
quả của kết quả ước lượng chúng ta cần xem xét một số yếu tố sau:
- Chỉ các chuyên gia được đào tạo, có kinh nghiệm và tay nghề được giao
nhiệm vụ xác định kích cỡ phần mềm và tham gia vào quá trình ước lượng.
- Những chuyên gia này cần được trang bị công cụ và công nghệ phù hợp.

8
- Người quản lý dự án cần xây dựng và chịu trách nhiệm hiệu chỉnh quy trình
ước lượng thống nhất trong toàn bộ vòng đời phát triển dự án.
Hiện nay, có nhiều phương pháp khác nhau để chuẩn bị đường mức ước lượng
có thể là phương pháp tiếp cận từ dưới lên (Bottom-Up), phương pháp đánh giá của
chuyên gia và mô hình chi phí…
 Phương pháp ước lượng từ dưới lên trên (Bottom-Up): phương pháp này
bao gồm việc phân rã hệ thống tới mức thấp nhất dạng chức năng hay nhiệm
vụ ở nút lá. Chi phí để thực hiện các thực thể ở trên khác nút lá sẽ bằng tổng
chi phí thực hiện của các phần tử nút lá thuộc thực thể này. Quá trình này sẽ

được lặp lại đến khi gặp thực thể ở mức cao nhất và giá trị tổng chi phí tính
được sẽ là chi phí để thực hiện dự án. Phương pháp này khá hiệu quả để ước
tính chi phí cho các hệ thống cỡ nhỏ vì những hệ thống này sẽ thuận lợi cho
việc phân rã nhỏ thành các module chức năng.
 Mô hình chi phí phần mềm: mỗi một mô hình chi phí phần mềm sẽ có tập
yêu cầu thông tin đầu vào khác nhau. Tuy nhiên, đa số các mô hình đều yêu
cầu người sử dụng cung cấp những đặc trưng của dự án dưới dạng các tham
số đầu vào để thực hiện tính toán. Những thông tin này có thể là thông tin
mô tả, các đặc trưng của dự án, kinh nghiệm và trình độ đào tạo của đội ngũ
phát triển dự án, phương thức và công cụ được sử dụng để hoàn thiện dự án.
Các mô hình chi phí dạng thông số cung cấp các phương tiện để áp dụng
một phương thức thống nhất cho mục đích chuyển đổi các tình huống không
rõ ràng thành các phân tích thống kê toán học chính xác. Do đó, nhiều nhà
nghiên cứu đã thừa nhận những mô hình chi phí phần mềm có tính bao quát
hơn so với các kĩ thuật ước lượng khác và giúp giảm thiểu sai số khi thực
hiện ước lượng chi phí phần mềm. Ngoài ra, mô hình còn được sử dụng như
một phương tiện để quản lý thông tin có tính chất mô tả dự án, hỗ trợ quá
trình phân tích và xác định những rủi ro có thể xảy ra.
 Mô hình ước lượng dựa vào các hạng mục công việc: một hình thức khác
được sử dụng để ước lượng các thành phần khác nhau của dự án phần mềm
được bắt đầu từ các đặc tả yêu cầu và quy mô của dự án. Những thông tin
này sẽ được dùng để xác định những hạng mục công việc cần thực hiện để
từ đó tính toán ra toàn bộ nỗ lực cần thiết để hoàn thành dự án. Kết quả của
quá trình sẽ cung cấp cho chúng ta bảng phân rã công việc thể hiện cách
thức tổ chức và thực hiện công việc cần thiết. Tài liệu này sẽ được sử dụng
để lập kế hoạch cho dự án và cung cấp thông tin nhiệm vụ cụ thể cần được
triển khai. Tuy nhiên, chúng ta cần lưu ý là tài liệu này không thể hiện dạng
danh mục những việc cần phải làm mà nội dung của nó thể hiện kiến trúc
các nhiệm vụ cần thực hiện. Khi toàn bộ những nhiệm vụ này được thực
hiện thì kết quả tương ứng với việc thoả mãn tất cả những thoả thuận ban

đầu được đưa ra.

9
2.2.6. Thẩm định và phân tích các rủi ro
Chúng ta phải thừa nhận rằng luôn luôn tiềm ẩn những rủi ro không thể lường
trước được trong quá trình thực hiện bất kì dự án nào. Tuy nhiên, vấn đề chúng ta cần
quan tâm là việc phân định rõ thế nào là rủi ro và rủi ro là gì. Với những vấn đề dễ
dàng được nhận diện và xử lý thì không cần đánh giá đó là mối đe doạ cho dự án. Rủi
ro là những vấn đề khiến chúng ta phải dành thời gian, chi phí để xử lý hoặc trầm
trọng hơn là mất sự kiểm soát những gì đang diễn ra.
Thông thường, sự kiện rủi ro có xẩy ra hay không được biểu diễn dưới dạng xác
suất sự kiện. Giá trị này được thể hiện bằng hai giá trị logic sau: 0 – không thể xảy ra
và 1 – chắc chắn sẽ xảy ra. Khi xác suất của rủi ro có giá trị bằng 1 thì rủi ro trở thành
vấn đề cần giải quyết vì nó chắc chắn sẽ xảy ra và sẽ ảnh hưởng tới quá trình phát triển
dự án. Với mỗi rủi ro chúng ta cần xác định những việc cần làm để giảm thiểu hoặc
tránh được ảnh hưởng của chúng. Quản lý rủi ro sẽ bao gồm những hành động cần
thực hiện để hạn chế hoặc loại bỏ rủi ro có thể xảy ra.
Quá trình quản lý rủi ro giúp chúng ta có thể xác định rõ những mối đe doạ có
thể xuất phát từ bên trong hoặc bắt nguồn từ các yếu tố ngoại cảnh tới quá trình thực
hiện dự án. Với những vấn đề có liên quan đến việc xác định kích cỡ và ước lượng
phần mềm sẽ có những ảnh hưởng tiêu cực. Nhiệm vụ của người quản lý dự án là đánh
giá triệt để các mối đe doạ tiềm ẩn để từ đó có thể xây dựng đối sách cần thiết nhằm
giảm thiểu hoặc hạn chế tác động khi vấn đề nảy sinh.
2.2.7. Kiểm định kết quả ƣớc lƣợng
Nếu xét đến vị trí trong quy trình mô tả ở hình 2-1 thì đến bước này kết quả ước
lượng được đảm bảo là chính xác và đáng tin cậy. Tuy nhiên, chúng ta vẫn cần thẩm
định lại phương pháp đã sử dụng và kết quả ước lượng nhằm đảm bảo tính thống nhất
của quá trình ước lượng. Việc làm này sẽ giúp chúng ta tin tưởng hơn vào độ chính
xác của dữ liệu ước lượng, khẳng định tính hiệu quả của phương pháp và quan trọng
hơn là chúng ta đã đi đúng lộ trình.

Có nhiều phương pháp khác nhau thực hiện thẩm định quá trình ước lượng. Đối
tượng cần đánh giá sẽ là quy trình xây dựng kế hoạch ước lượng và bản thân quá trình
ước lượng. Thông thường, để đảm bảo tính khách quan khi thẩm định công việc này sẽ
do một thành viên không tham gia quá trình ước lượng chi phí dự án thực hiện. Nhằm
tăng tính chính xác cho công việc thẩm định, cần sử dụng nhiều phương pháp và công
cụ khác nhau để thực hiện các bước so sánh kết quả phân tích.
Chúng ta cần dựa vào những giả định được sử dụng trong quá trình ước lượng
để thẩm định phương pháp ước tính. Ngoài ra, chúng ta cũng cần đảm bảo là các quy
tắc nghiệp vụ được sử dụng thống nhất trong toàn bộ quá trình ước lượng. Nếu chúng
ta ước tính chi phí thấp và không lường hết các rủi ro có liên quan đến những yêu cầu
đặc biệt sẽ dẫn tới việc đánh giá thấp hoặc coi nhẹ những yếu tố này.
Những giả định sai lầm, dữ liệu không đáng tin cậy và độ lệch ước lượng sẽ
được phát hiện thông qua quy trình thẩm định hợp lý. Điều này sẽ giúp chúng ta hiểu

10
rõ hơn những rủi ro gắn liền với bản kế hoạch thực hiện ước lượng chi phí phần mềm.
Thông qua việc tách những vấn đề từ nguồn gốc phát sinh ra chúng, chúng ta có thể
xây dựng kế hoạch để ngăn chặn những rủi ro có liên quan đến những vấn đề đó, đồng
thời chúng ta có thể xác định rõ những nhiệm vụ cần thực hiện để hoàn thành dự án
với nguồn lực cho trước.
2.2.8. Xây dựng kế hoạch thực thi dự án
Quá trình xây dựng kế hoạch thực thi dự án bao gồm việc sử dụng kết quả ước
tính và việc phân bổ chi phí, lịch biểu thời gian thành các chức năng và cấu trúc phân
chia công việc thành từng nhiệm vụ.
Sự thành bại của một dự án chịu ảnh hưởng rất lớn bởi vai trò của người quản
lý dự án. Người quản lý dự án cần phải dám đối mặt và kịp thời thiết lập đối sách cho
những thách thức của hiện tại để có thể loại bỏ những rủi ro có thể xảy ra ở tương lai.
Một người quản lý dự án được đánh giá là thực hiện tốt nhiệm vụ của mình nếu sở hữu
kinh nghiệm phong phú về lĩnh vực và kĩ thuật phát triển phần mềm, là người có khả
năng lãnh đạo các thành viên trong nhóm, có khả năng phân tích những vấn đề tiềm ẩn

và có thể xây dựng kế hoạch hoạt động của dự án nhằm đạt tới mục tiêu hoàn thành dự
án đúng tiến độ, với nguồn chi phí cho trước.
2.2.9. Xây dựng tài liệu cho quá trình ƣớc lƣợng
Ở thời điểm kết thúc quá trình phát triển dự án phần mềm, chúng ta nên lập tài
liệu nhằm lưu lại những thông tin quan trọng tạo nên quá trình ước lượng cũng như
những bài học rút ra được từ việc thực hiện ước lượng chi phí phần mềm. Việc làm
này sẽ là căn cứ chứng minh rằng những hạng mục công việc chúng ta thực hiện là
hợp lệ, kết quả của quá trình ước lượng là đáng tin cậy. Nội dung của tài liệu này là
những quyết định quan trọng được đưa ra trong quá trình xây dựng quy trình ước
lượng, kết quả và những tác động của những hoạt động đã được thực hiện. Tài liệu này
cũng nên đề cập tới những thông tin còn thiếu, những rủi ro, những vấn đề phức tạp đã
nảy sinh trong quá trình ước lượng. Cuối cùng, trong tài liệu này cũng không thể thiếu
thông tin mô tả quá trình kết hợp của các thành viên trong đội ước lượng, quá trình
trao đổi với khách hàng, sự đánh đổi mà chúng ta đã thực hiện để làm rõ các vấn đề
phát sinh trong quá trình ước tính chi phí dự án.
Thời điểm thích hợp nhất để đánh giá, tổng kết để rút ra những bài học kinh
nghiệm từ dự án là ngay khi quá trình phát triển dự án kết thúc vì khi đó các thành
viên tham gia vẫn còn có thể nhớ chi tiết các vấn đề đã diễn ra. Quá trình họp đánh giá
có thể chỉ là tiến hành ở mức nhỏ chỉ có ít nhất hai thành viên phát triển dự án tham
gia cho đến mức cao hơn là những buổi họp có sự tham gia của các thành viên tham
gia trả lời phiếu điều tra, khảo sát nhằm tiến tới thống nhất những vấn đề chính yếu có
ảnh hưởng tới quy trình ước lượng chi phí phát triển dự án phần mềm. Dự án phát triển
phần mềm được xem như là cơ hội tốt để tổ chức cải tiến quy trình ước lượng chi phí
và là cơ sở để chuẩn bị tốt hơn nữa cho những dự án tiếp theo.

11
2.2.10. Đánh giá dự án thông qua quá trình phát triển
Những thông tin liên quan đến quá trình phát triển dự án cần được tập hợp lại
làm cơ sở để so sánh với kế hoạch ban đầu. Chúng ta cần xem xét lại toàn bộ quy trình
ước lượng trong trường hợp chi phí thực tế cần để hoàn thành dự án khác xa so với kế

hoạch đã đề ra. Thông thường, chúng ta cần thu thập lại dữ liệu của những đặc trưng
sau của dự án:
- Yếu tố chi phí ở khía cạnh nỗ lực của nhân viên, nỗ lực ở từng giai đoạn và
nỗ lực tổng thể của dự án.
- Những thiếu sót được tìm ra và đối sách và chi phí để khắc phục chúng.
- Đặc trưng của quy trình phát triển dự án như ngôn ngữ lập trình, mô hình
phát triển và công nghệ.
- Những thay đổi về đặc tả yêu cầu, lịch biểu phát triển.
- Kiến trúc phần mềm ở khía cạnh quy mô và độ phức tạp.
Công việc ước tính chi phí phần mềm, lập kế hoạch thực hiện và xác định rủi ro
là những công việc khó khăn nhưng có ảnh hưởng rất lớn tới sự thành công của dự án.
Kết quả công việc sẽ hiệu quả nếu chúng ta xây dựng tiêu chuẩn hoá cho quy trình ước
lượng và được kiểm nghiệm ở nhiều dự án khác nhau. Quy trình ước lượng mô tả ở
hình 2-2 sẽ thay đổi theo nhu cầu thực tế của từng tổ chức, tuỳ theo quan điểm đánh
giá những hạng mục công việc được cho là quan trọng, cần tập trung thời gian và nhân
lực để thực hiện.
2.3. Một số phƣơng pháp ƣớc lƣợng chi phí phát triển phần mềm
Hiện nay, trên thế giới có nhiều phương pháp ước lượng chi phí khác nhau được
sử dụng nhưng nhìn chung các phương pháp này thuộc một trong ba nhóm phương
pháp sau:
 Phương pháp dùng mô hình toán học: là nhóm sử dụng các công thức toán
học và các tham số đầu vào để tính toán nỗ lực và thời gian cần thiết để
hoàn thành dự án. Những mô hình toán học phổ biến gồm có mô hình
COCOMO (Constructive COst MOdel) (Boehm 1981) và kĩ thuật phân tích
điểm chức năng (Albrecht & Gaffney 1983) [3].
 Phương pháp đánh giá của chuyên gia: là nhóm phương pháp dự đoán chi
phí dựa trên kinh nghiệm và kĩ năng của một hoặc nhiều chuyên gia phần
mềm.
 Phương pháp ước lượng dựa trên lập luận: là nhóm phương pháp so sánh
dự án cần ước tính với những dự án đã thực hiện và hoàn thành trước đó để

tìm ra các dự án tương tự làm cơ sở để ước lượng chi phí cần thiết hoàn
thành dự án mới.
2.3.1. Mô hình COCOMO
COCOMO là mô hình do Barry Boehm thiết kế nhằm ước tính công sức, thời
gian và số người-tháng (man-month) cần thiết để phát triển dự án dựa trên kích cỡ

12
phần mềm. Mô hình này rất phù hợp để ước tính cho các phần mềm kích cỡ lớn. Mô
hình này dựa trên kết quả khảo sát 60 dự án tại các công ty TRW, Northrop Grumman
từ năm 2002[7]. Kết quả nghiên cứu đã được xây dựng thành chương trình viết bằng
ngôn ngữ PL/I và bao gồm hơn 100,000 dòng lệnh.
Mô hình COCOMO gồm có 3 dạng sau:
 COCOMO cơ bản: mô hình cho giá trị đơn, chi phí được tính dựa trên số
lượng dòng lệnh tạo nên phần mềm.
 COCOMO trung gian: chi phí được tính theo độ lớn phần mềm theo số
dòng lệnh và cộng thêm đánh giá sản phẩm, phần cứng, nguồn nhân lực và
các thuộc tính của dự án.
 COCOMO chi tiết: tích hợp mọi đặc trưng của mô hình COCOMO trung
gian nhưng có bổ sung thêm đánh giá của chi phí ảnh hưởng trong mỗi giai
đoạn của quy trình công nghệ phần mềm.
2.3.1.1. COCOMO cơ bản
Mô hình có thể áp dụng cho ba lớp dự án phần mềm
 Dự án với quy mô nhỏ: dự án phần mềm đơn giản và có cấu trúc rõ ràng,
đội ngũ tham gia phát triển nhỏ, có kinh nghiệm phát triển ứng dụng cùng
loại và làm việc trên môi trường với những yêu cầu không quá khắt khe.
 Dự án phần mềm nửa gắn kết: đội ngũ tham gia phát triển có kinh nghiệm
về nhiều lĩnh vực khác nhau và làm viêc trên môi trường với những yêu cầu
không quá khắt khe.
 Dự án nhúng: được triển khai trong điều kiện chặt chẽ về phần cứng, phần
mềm và có cả những ràng buộc về điều kiện vận hành.

Công thức tính toán của mô hình COCOMO cơ bản có dạng:
DEPEcDKLOCaE
bb
d
b
b
b
/;)(;)( 

Trong đó:
E - ước tính người/tháng.
D - thời gian triển khai, tính theo tháng.
KLOC – ước tính số dòng lệnh (đơn vị = 1000 dòng lệnh) của sản phẩm
dự án phần mềm.
P – số lượng người cần cho dự án.
Hệ số a
b
, b
b
, c
b
, d
b
được cho bởi bảng sau đây:

Dự án phần mềm
a
b

b

b

c
b

d
b

Quy mô nhỏ
2.4
1.05
2.5
0.38
Nửa gắn kết
3.0
1.12
2.5
0.35
Nhúng
3.6
1.20
2.5
0.32
Bảng 2 - 1. Bảng hằng số dùng trong tính toán bằng phương pháp COCOMO cơ bản

13

Mô hình COCOMO cơ bản rất phù hợp cho ước tính thô vì dễ dàng và thực
hiện nhanh. Tuy nhiên, kết quả tính toán có độ chính xác không cao vì thiếu một số
nhân tố, chưa kể đến sự khác nhau trong ràng buộc về phần cứng, kinh nghiệm và khả

năng chuyên nghiệp của con người. Ngoài ra, việc sử dụng các công cụ hiện đại và các
đặc trưng khác cũng sẽ ảnh hưởng tới độ chính xác của kết quả ước lượng.
2.3.1.2. COCOMO trung gian
Mô hình COCOMO trung gian là sự cải tiến của mô hình COCOMO cơ bản và
được dùng để ước tính thời gian lập trình trong triển khai sản phẩm phần mềm. Sự cải
tiến này nếu xem xét trên một tập hợp “Chi phí của các đặc trưng các bộ phận điều
phối” thì được chia thành 4 nhóm sau:
 Đặc trưng của phần mềm
- Yêu cầu về độ tin cậy của phần mềm.
- Độ lớn CSDL của ứng dụng.
- Độ phức tạp của phần mềm.
 Đặc trưng của phần cứng.
- Ràng buộc về tính năng vận hành.
- Ràng buộc về bộ nhớ.
- Tính không ổn định của môi trường máy ảo.
- Yêu cầu về thời gian chuyển hướng (turnabout time).
 Đặc trưng về chuyên gia
- Khả năng phân tích vấn đề.
- Khả năng về kĩ nghệ phần mềm.
- Kinh nghiệm phát triển ứng dụng.
- Kinh nghiệm về máy ảo.
- Kinh nghiệm sử dụng ngôn ngữ lập trình.
 Đặc trưng về dự án
- Sử dụng các công cụ phần mềm.
- Khả năng ứng dụng các phương pháp của kĩ nghệ phần mềm.
- Yêu cầu về lịch biểu triển khai dự án.
Mỗi đặc trưng trên sẽ được đánh giá và cho điểm theo thang điểm có 6 mức từ
rất chậm đến quá cao. Dựa trên thang điểm, hệ số nỗ lực sẽ được tính theo bảng xếp
hạng sau:

Rất
chậm
Chậm
Bình
thƣờng
Cao
Rất
cao
Quá
cao
Đặc trưng của phần mềm
Yêu cầu về độ tin cậy của phần
mềm
0.75
0.88
1.00
1.15
1.40


14
Độ lớn CSDL của ứng dụng

0.94
1.00
1.08
1.16

Độ phức tạp của phần mềm

0.70
0.85
1.00
1.15
1.30

Đặc trưng của phần cứng
Ràng buộc về tính năng vận hành
1.00
1.11
1.30
1.66


Ràng buộc về bộ nhớ
1.00
1.06
1.21
1.56


Tính không ổn định của môi trường
máy ảo
0.87
1.00
1.15
1.30


Yêu cầu về thời gian chuyển hướng

0.87
1.00
1.07
1.15


Đặc trưng về chuyên gia
Khả năng phân tích vấn đề
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 phát triển ứng dụng
1.42
1.17
1.00
0.86
0.70

Kinh nghiệm về máy ảo
1.21

1.10
1.00
0.90


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


Đặc trưng của dự án
Sử dụng các công cụ phần mềm
1.24
1.10
1.00
0.91
0.82

Khả năng ứng dụng kĩ nghệ phần
mềm
1.24
1.10
1.00
0.91
0.83

Yêu cầu về lịch biểu triển khai dự

án
1.23
1.08
1.00
1.04
1.10

Bảng 2 - 2. Thang điểm đánh giá các đặc trưng của dự án

Công thức tính toán của mô hình COCOMO trung gian có dạng
xEAFKLOCaE
i
b
i
)(

Trong đó:
E – ước tính người/tháng.
KLOC – ước tính số dòng lệnh (đơn vị = 1000 dòng lệnh) của sản phẩm
dự án phần mềm.
EAF (Effort Adjustment Factor) – được tính theo bảng trên.
Hệ số a
i
và b
i
được cho bởi bảng sau:

15
Dự án phần mềm
a
i

b
i

Quy mô nhỏ
3.2
1.05
Nửa gắn kết
3.0
1.12
Nhúng
2.8
1.20
Bảng 2 - 3. Bảng hệ số tính bằng phương pháp COCOMO trung gian
2.3.2. Mô hình điểm chức năng (Function Point)
Mô hình điểm chức năng là kết quả nghiên cứu của A.Albrecht với mục đích để
ước tính số dòng lệnh tạo nên phần mềm và dựa trên cơ sở đó để ước tính kích cỡ của
phần mềm. Điểm chức năng tính kích cỡ phần mềm bằng phương pháp xác định số
lượng các chức năng mà hệ thống cung cấp cho người sử dụng dựa trên các yếu tố
thiết kế logic và đặc tả chức năng.
Số lượng dòng lệnh (LOC – Lines of Code) được tính theo công thức sau:
LOC = FPs của hệ thống * LOC/FP của ngôn ngữ
Trong đó:
FPs – số điểm chức năng.
LOC/FP – số dòng lệnh cho một chức năng theo ngôn ngữ lập trình, tham khảo
bảng dưới đây

Ngôn ngữ lập trình
LOC/FP
Hợp ngữ
320
Ngôn ngữ C
128
COBOL
106
FORTRAN
106
Pascal
90
Ngôn ngữ C++
64
Ada95
53
Visual Basic
32
SmallTalk
22
PowerBuilder
16
SQL
12
Bảng 2 - 4. Bảng quy đổi số dòng lệnh trong một chức năng của các ngôn ngữ lập trình

Mô hình điểm chức năng gồm những bước sau:
Bước 1: tính điểm chức năng của 5 loại tiêu biểu.

16
- Số kiểu người dùng nhập dữ liệu vào (kí hiệu là I – External Input).
- Số kiểu người dùng xuất dữ liệu ra (kí hiệu là O – External Output).
- Số kiểu người dùng yêu cầu (kí hiệu là E – External Inquiry).
- Số giao diện ngoại vi (kí hiệu là F – External Interface Files).
- Số file liên quan (kí hiệu là L – Internal Logical Files).
Bước 2: với mỗi kiểu chức năng, thực hiện ước lượng độ phức tạp của nó và nhân với
hệ số đặc trưng và cộng lại.
- Độ phức tạp có 3 mức: đơn giản, trung bình và phức tạp.
- Xác định và tính trọng số điều chỉnh cho mỗi loại (F
i
) dựa trên kinh nghiệm tổ
chức .
- Tính tổng của toàn bộ số điều chỉnh điểm chức năng (

i
F
).
Bước 3: ước lượng hệ số điều chỉnh (F
i
, i = 1 14) bằng cách trả lời các câu hỏi:
- Hệ thống có yêu cầu lưu trữ và phục hồi với độ tin cậy cao không?
- Có cần những dữ liệu giao tiếp không?
- Có các chức năng phân tán không?
- Việc thực hiện có đạt yêu cầu không?
- Hệ thống có vận hành trên một môi trường đã tồn tại không?
- Hệ thống có yêu cầu nhập dữ liệu trực tuyến không?
- Có cần xây dựng nhiều màn hình và chức năng để nhập dữ liệu trực tuyến
không?
- Các file dữ liệu có được cập nhật trực tuyến không?

- Việc nhập, xuất và truy vấn dữ liệu có phức tạp không?
- Logic nghiệp vụ bên trong có phức tạp không?
- Có dùng lại được mã lệnh thiết kế chương trình không?
- Sự chuyển đổi và cài đặt có bao gồm trong thiết kế hay không?
- Hệ thống có cho phép tạo nhiều bộ cài đặt cho các tổ chức khác nhau không?
- Thiết kế của hệ thống có dễ sử dụng, dễ sửa đổi không?
Sau đó, mỗi câu trả lời cho những câu hỏi trên sẽ được cho điểm từ 0 (N/A) đến 5
(Absolutely Essential). Cuối cùng, thực hiện tính tổng giá trị điều chỉnh

i
F
.
Bước 4: tính điểm chức năng theo công thức sau
FPs = Tổng điểm * (0.65 + 0.01*

i
F
)
Trong đó: 0.65 và 0.01 là hệ số theo kinh nghiệm.
2.3.3. Phƣơng pháp chuyên gia
Dự báo có vai trò rất quan trọng trong quá trình ra quyết định quản lý với bất kì
lĩnh vực nào, ngành nào trong nền kinh tế quốc dân trong đó có ngành Công nghệ
thông tin. Với những bài toán không thể thu thập được các số liệu lịch sử, việc sử dụng
các phương pháp dự báo dựa trên các công cụ chính xác của toán học không giải quyết
được và khi đó phương pháp chuyên gia được các nhà dự báo tập trung nghiên cứu và
coi như con đường đúng đắn để có thể đi đến mục tiêu. Phương pháp chuyên gia là

17
phương pháp dự báo sẽ đưa ra những dự báo khách quan về tương lai phát triển của
lĩnh vực hẹp của khoa học kĩ thuật hoặc sản xuất dựa trên việc xử lý các đánh giá của

chuyên gia. Ưu điểm của phương pháp là thực hiện nhanh, chi phí thấp. Tuy nhiên,
nhược điểm của phương pháp là độ chính xác phụ thuộc vào trình độ chuyên môn của
các chuyên gia dự đoán và bài toán cụ thể.
Chi tiết các bước thực hiện như sau:
Bước 1: Lựa chọn và thành lập nhóm chuyên gia dự báo và nhóm các nhà phân tích
Các chuyên gia công nghệ phần mềm nghiên cứu tài liệu và đưa ra những đánh
giá dự báo. Đây là các chuyên gia có trình độ hiểu biết chung tương đối cao ngoài lĩnh
vực hẹp của mình, có kiến thức chuyên sâu về lĩnh vực dự báo, có lập trường khoa học
và có khả năng tiên đoán thể hiện ở sự phản ánh nhất quán xu thế phát triển của đối
tượng dự báo và có định hướng, suy nghĩ về tương lai trong lĩnh vực mình quan tâm.
Nhóm chuyên gia phân tích còn gọi là nhóm các nhà quản lý bao gồm những
nguời có cương vị lãnh dạo, những nguời có quyền quyết định chọn phương pháp dự
báo. Ðây cũng là các chuyên gia có trình độ chuyên môn cao về vấn dề cần dự báo, có
kiến thức về dự báo và chuyên gia phân tích còn phải có lòng kiên nhẫn, tính lịch thiệp
do quá trình tiếp xúc và hợp tác với các chuyên gia là một quá trình phức tạp.
Bước 2: Trưng cầu ý kiến của các chuyên gia
Trưng cầu ý kiến của các chuyên gia là một giai đoạn của phương pháp chuyên
gia. Tùy theo đặc điểm thu nhận và xử lý thông tin mà chọn những phương pháp trưng
cầu cơ bản như: trưng cầu ý kiến theo nhóm và cá nhân, trung cầu vắng mặt và có mặt
và trưng cầu trực tiếp hay gián tiếp. Nếu ý kiến đánh giá của các chuyên gia có sự khác
biệt đáng kể thì cần tiến hành thảo luận lại và đưa ra đánh giá mới.
Bước 3: Xử lý ý kiến chuyên gia
Sau khi thu thập ý kiến của các chuyên gia, cần phải tiến hành một loạt các biện
pháp xử lý các ý kiến này. Ðây là bước quan trọng để đưa ra kết quả dự báo. Nói
chung có hai dạng vấn dề cần giải quyết khi xử lý ý kiến chuyên gia:
- Ðánh giá thời gian hoàn thành sự kiện.
- Ðánh giá tầm quan trọng tương đối giữa các sự kiện, chẳng hạn như đánh giá
vai trò của các yếu tố chi phí đối với quy trình ước lượng.
Nếu đánh giá mới không sai khác nhiều với kết quả trước đó thì quá trình này
sẽ dừng lại. Ngược lại, quay lại bước 2.

2.4. Tóm tắt chƣơng
Phần mềm máy tính đóng vai trò vô cùng quan trọng đối với hệ thống máy tình
và ngày càng trở nên đắt đỏ so với phần cứng. Chúng ta cũng đã thấy các phần mềm
máy tính là rất đa dạng và phong phú, chúng thuộc rất nhiều lĩnh vực khác nhau và hầu
như thâm nhập vào mọi hoạt động của đời sống xã hội loài người. Tuy đã đạt được
những thành tựu đáng kể nhưng rất nhiều dự án phần mềm lớn vẫn bị chậm và vượt
quá dự toán ngân sách ban đầu. Do nhu cầu của thực tiễn, ngành công nghiệp phần
mềm đang đứng trước thách thức vô cùng to lớn, đó là làm sao xây dựng được các

18
phần mềm tốt theo một lịch trình và kinh phí định trước, đáp ứng được yêu cầu thực
tiễn sự tiến hóa của phần cứng và những đòi hỏi đa dạng của người dùng. Để làm được
điều này, mỗi doanh nghiệp phần mềm cần xây dựng cho mình một quy trình tiêu
chuẩn nhằm thực hiện ước tính chi phí phát triển phần mềm và cần tuyệt đối tuân thủ
trong suốt quá trình thực hiện dự án. Các doanh nghiệp có thể lựa chọn cho mình
phương pháp hỗ trợ cho công việc ước lượng tùy theo năng lực và kinh nghiệm của
mình. Những dữ liệu có liên quan đến quy trình ước lượng cũng cần được lưu giữ lại
làm tài liệu tham khảo hữu ích cho những dự án tiếp theo.



