Ước lượng chi phí phần mềm bằng CBR

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

Tô Lan Hƣơng

ƢỚC LƢỢNG CHI PHÍ PHẦN MỀM BẰNG CBR

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Ệ

Tô Lan Hƣơng

ƢỚC LƢỢNG CHI PHÍ PHẦN MỀM BẰNG CBR

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:

GS.PTS Nguyễn Việt Hà

Hà Nội - 2010


1/71

MỤC LỤC
LỜI CẢM ƠN..................................................................
KÝ HIỆU VIẾT TẮT...................................................................................................
DANH MỤC BẢNG.....................................................................................................
DANH MỤC HÌNH VẼ ...............................................................................................

MỞ ĐẦU
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.4
1.5
2. CHƢƠNG 2 LẬP LUẬN TRÊN KINH NGHIỆM............................................

2.1.
2.2.
2.3.
2.4.
3. CHƢƠNG 3 ÁP DỤNG LẬP LUẬN THEO KINH NGHIỆM VÀO ƢỚC

LƢỢNG CHI PHÍ PHẦN MỀM................................................................................ 40
3.1.

Bài toán đặt ra................................................................................................ 41

3.2.

Thiết kế ca sử dụng hệ thống......................................................................... 42

3.3.

Thiết kế chức năng hệ thống.......................................................................... 43

3.3.1. Tìm kiếm....................................................................................................... 44
3.3.2. Hiệu chỉnh..................................................................................................... 48
3.4.

Thiết kế màn hình chức năng......................................................................... 49

3.5.

Thiết kế cơ sở dữ liệu.................................................................................... 50

3.5.1. Biểu diễn dự án.............................................................................................. 50
3.5.2. Tổ chức lưu trữ.............................................................................................. 52


2/71
4. CHƢƠNG 4 THỰC NGHIỆM............................................................................ 53
4.1.

Chương trinh̀ thưcc̣ nghiêm............................................................................. 54

4.1.1. Ngôn ngữ lập trình và thư viện...................................................................... 54
4.1.2. Cài đặt chương trình...................................................................................... 54
4.2.

Thực nghiệm.................................................................................................. 54

KẾT LUẬN................................................................................................................... 58
PHỤ LỤC..................................................................................................................... 59


3/71

KÝ HIỆU VIẾT TẮT
CBR

Case-based Reasoning

COCOMO

COnstructive COst MOdel

AI

Aritificial Intelligence

SLIM

Software LIfe-cycle Model

WBS

Work Breakdown Structure

OLS

Ordinary Least Squares

EAF

Effort Adjustment Factor

NOP

Number of Object Point

LOC

Line Of Code

CSDL

Cơ sở dữ liệu

UC

Use Case


4/71

DANH MỤC BẢNG
Bảng 1 Hệ số các mode trong mô hình COCOMO
Bảng 2 Các tham số hiệu chỉnh trong mô hình COCOMO

Bảng 3 Tham số hiệu chỉnh trong mô hình tiền thiết kế
Bảng 4 Các thừa số hiệu chỉnh của mô hình hậu kiến trúc
Bảng 5 Các hệ số hiệu chỉnh mũ
Bảng 6 Bảng so sánh các phương pháp ước lượng chi phí
Bảng 7 Bảng giá trị thuộc tính đặc trưng dự án
Bảng 8 Bảng các giá trị trọng số
Bảng 9 Kết quả ước lượng các dự án thực nghiệm 1
Bảng 10 Kết quả ước lượng các dự án thực nghiệm 2
Bảng 11 Bảng danh sách dự án trong CSDL ước lượng
Bảng 12 Bảng dự án mới đưa vào ước lượng
Bảng 13 Bảng danh sách các dự án đối chứng ước lượng
Bảng 14 Độ tương quan giữa các giá trị thuộc tính Hiện trạng hệ thống
Bảng 15 Độ tương quan giữa các giá trị thuộc tính Ngôn ngữ lập trình
Bảng 16 Độ tương quan giữa các giá trị thuộc tính Hệ quản trị CSDL
Bảng 17 Độ tương quan giữa các giá trị thuộc tính Dạng phần mềm
Bảng 18 Độ tương quan giữa các giá trị thuộc tính Yêu cầu phi chức năng
Bảng 19 Độ tương quan giữa các giá trị thuộc tính Mô hình CSDL
Bảng 20 Độ tương quan giữa các giá trị thuộc tính Loại dự án


5/71

DANH MỤC HÌNH VẼ
Hình 1 Các kỹ thuật ước lượng theo giai đoạn
Hình 2 Phân phối Rayleigh cho nỗ lực phát triển [4]
Hình 3 Đầu vào và đầu ra của mô hình ước lượng SEER-SEM
Hình 4 Các bước thực hiện ước lương theo Delphi
Hình 5 Các bước thực hiện của CBR
Hình 6
Chu trình lập luận theo kinh nghiệm.

Hình 7
Đồ thị biểu diễn ca lập luận [2]
Hình 8
Cây quyết định
Hình 9
Biều đồ luồng Use case hệ thống
Hình 10 Biểu đồ luồng xử lý chức năng
Hình 11 Luồng màn hình quản lý dự án
Hình 12 Luồng màn hình ước lượng dự án
Hình 13
Màn hình danh mục dự án
Hình 14
Màn hình Tìm kiến dự án
Hình 15
Màn hình kết quả tìm kiếm
Hình 16
Màn hình Hiệu chỉnh


6/71

MỞ ĐẦU
Trong kỷ nguyên công nghệ và nền kinh tế đa chiều, phần mềm đã và đang đóng một
vai trò vô cùng quan trọng trong việc định hướng phát triển cho mọi doanh nghiệp và góp
phần gia tăng giá trị cạnh tranh trong cộng đồng. Tại Việt Nam tổng doanh thu từ ngành công
nghệ thông tin năm 2008 là 4,074 tỷ USD [1].
Xây dựng các dự án phần mềm thành công luôn là mối quan tâm hàng đầu đối với mọi
tổ chức doanh nghiệp. Đặc biệt quan trọng là quá trình quản lý, kiểm soát tiến độ và chất
lượng dự án.
Quản trị dự án là một quá trình thực hiện các hoạt động hoạch định, tổ chức, điều

khiển và kiểm soát các giai đoạn của một dự án từ khâu hình thành, thẩm định, triển khai và
vận hành dự án theo một mục tiêu nhất định, đến đánh giá hiệu quả đạt được của dự án trong
từng thời kỳ và trong cả thời hạn đầu tư , đồng thời phối hợp các giai đoạn của dự án với nhau
làm cho dự án hoạt động nhịp nhàng và có hiệu quả cao.
Các vấn đề thường xảy ra đối với một dự án phần mềm


Thời gian thực hiện dự án vượt mức dự kiến



Chi phí thực hiện dự án vượt mức dự kiến



Kết quả của dự án không như dự kiến



Phát sinh rủi ro

Vì vậy quá trình ước lượng cho dự án phần mềm ban đầu là quá trình rất quan trọng và
quyết định lớn vào thành công của dự án.
Ước lượng sớm và chính xác chi phí dự án phần mềm từ lâu đã là một thách thức lớn
đối với các nhà quản trị dự án. Đã có một vài mô hình ước lượng được đề xuất và áp dụng
trong thực tế như COCOMO, SLIM (Putnam)... Tuy nhiên, những mô hình này đều cứng
nhắc và có độ tin cậy không cao, nhất là khi áp dụng vào những giai đoạn đầu của quá trình
phát triển. Luận văn này áp dụng phương pháp lập luận theo kinh nghiệm để giải quyết bài
toán trên: xây dựng một mô hình hỗ trợ ước lượng dự án phần mềm. Hướng tiếp cận của mô
hình là sử dụng mô hình lập luận theo tình huống (Case-based reasoning- CBR) - một mô

hình suy luận thường thấy ở các chuyên gia. Trong mô hình CBR, chi phí cho một dự án được


7/71
ước lượng bằng cách tìm kiếm những dự án tương tự đã trong quá khứ và hiệu chỉnh chi phí
của các dự án đó cho phù hợp với ngữ cảnh của dự án mới. Mô hình này có thể áp dụng được
ngay tại những pha ban đầu của quá trình phát triển khi dữ liệu phân tích còn chưa đầy đủ.
Luận văn nghiên cứu về ước lượng chi phí đặc biệt là phương pháp lập luận theo tình
huống CBR áp dụng cho ước lượng chi phí phần mềm và chúng tôi có thực hiện xây dựng
chương trình ước lượng vâṇ dungc̣ vào ước lươngc̣ dư ác̣ n taịđơn vi đc̣ ang công tác trong đócó cải
tiến một số thông số biểu diễn dự án và đầu ra ước lượng.
Các phần còn lại của luận văn có cấu trúc như sau. Chương 1 trình bày khái quát về
ước lượng chi phí phần mềm. Chương 2 trình bày về lý thuyết phương pháp lập luận trên kinh
nghiệm CBR. Chương 3 đưa ra cách thức chi tiết trong áp dụng phương pháp CBR vào ước
lượng chi phí phần mềm. Chương 4 mô tả thực nghiệm với hệ thống các dự án tại đơn vị công
tác và có đánh giá kết quả thực nghiệm. Chương 5 tổng kết lại những kết quả đạt được sau
quá trình nghiên cứu và hướng nghiên cứu tiếp theo.


8/71

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

Trong chương này giới thiệu tổng quan về quản lý dự án và ước lượng chi phí phần
mềm, những khó khăn gặp phải trong quá trình ước lượng chi phí của một dự án phần mềm.
Từ đó đưa ra một số phương pháp phổ biến được áp dụng trong quá trình ước lượng dự án
phần mềm, đánh giá ưu nhược điểm của các phương pháp làm cơ sở cho quá trình lựa chọn
CBR trong ước lượng chi phí dự án phần mềm.

______________________________________________________________



Tổng quan quá trình quản lý dự án



Tổng quan ước lượng chi phí dự án phần mềm



Bài toán đặt ra



Giới thiệu các phương pháp ước lượng.



Đánh giá ưu nhược điểm các phương pháp ước lượng.

______________________________________________________________


9/71
1.1 Quản lý dự án phần mềm
Trong thuật ngữ của chuyên ngành kỹ nghệ phần mềm, Quản lý dự án phần mềm là
các hoạt động trong lập kế hoạch, giám sát và điều khiển tài nguyên dự án (ví dụ như kinh
phí, con người), thời gian thực hiện, các rủi ro trong dự án và cả quy trình thực hiện dự án;
nhằm đảm bảo thành công cho dự án [1]. Quản lý dự án phần mềm cần đảm bảo cân bằng
giữa ba yếu tố: thời gian, tài nguyên và chất lượng. Ba yếu tố này được gọi là tam giác dự án.

Các vấn đề thường xảy ra đối với một dự án phần mềm





Thời gian thực hiện dự án vượt mức dự kiến



Chi phí thực hiện dự án vượt mức dự kiến

Kết quả của dự án không như dự

kiến Trách nhiệm của người quản lý dự án


Quản lý thời gian: Lập lịch, kiểm tra đối chiếu quá trình thực hiện dự án

với lịch trình, điều chỉnh lịch trình khi cần thiết


Quản lý tài nguyên: xác định, phân bổ và điều phối tài nguyên



Quản lý sản phẩm: thêm, bớt các chức năng phù hợp với yêu cầu của

khách hàng


Quản lý rủi ro: xác định, phân tích rủi ro và đề xuất giải pháp khắc phục



Tổ chức cách làm việc

Chính vì vậy việc ước lượng chi phí là khâu quyết định của các doanh nghiệp sản xuất
phần mềm trong việc thúc đẩy sản xuất và đưa ra những quyết định đúng đắn về tài chính của
doanh nghiệp.
1.2 Ƣớc lƣợng chi phí dự án phần mềm
Ước lượng chi phí và thời gian thực hiện dự án quan trọng không chỉ bởi có ảnh
hưởng đến chất lượng sản phẩm mà còn có thể ảnh hưởng trực tiếp tới chiến lược phát triển
lâu dài của cả công ty.
Trước thập kỷ 70, người ta thường tìm cách áp dụng những phương pháp ước lượng
truyền thống của công nghiệp chế tạo để ước lượng dự án phần mềm. Tuy nhiên, do phần
mềm là một sản phẩm trí tuệ đặc biệt, không có phép đo trực tiếp nên các phương pháp ước


10/71
lượng này tỏ ra không hiệu quả. Sang thập kỷ 80 và 90, một vài mô hình đặc thù đã được đề
xuất nhằm nâng cao độ chính xác của các ước lượng (SLIM, PRICES, COCOMO,
ESTIMACS . . . )[4]. Vào thời điểm đề xuất, các mô hình này đều khẳng định là sẽ cho kết
quả chấp nhận được nhưng sau một thời gian ứng dụng, kết quả thu được vẫn có thể có sai số
tới 300 - 400%. Nguyên nhân của sự sai khác trên là do chúng đều được xây dựng dựa trên cơ
sở các mô hình thống kê trừu tượng và xem xét các yếu tố ngữ cảnh một cách cứng nhắc.
Trong khi đó, phát triển phần mềm lại là lĩnh vực luôn vận động và biến đổi không ngừng và
phụ thuộc nhiều vào những yếu tố khách quan bên ngoài. Ngoài ra, hầu hết các mô hình được
đề xuất đều đòi hỏi thông tin đầu vào tương đối chi tiết (kích thước dự án, kích thước dữ
liệu...). Vì thế, nếu áp dụng vào những giai đoạn đầu của quá trình phát triển (giai đoạn đòi

hỏi ước lượng) sẽ cho kết quả không chính xác. Trên thực tế, để đảm bảo độ tin cậy, các
chuyên gia vẫn thường phải ước lượng dựa trên kinh nghiệm và phán đoán chủ quan của
mình.
Trong những năm gần đây, khoa học máy tính nói chung và ngành trí tuệ nhân tạo (AI)
nói riêng đã có những bước tiến đáng kể [9]. Nhiều quá trình đòi hỏi óc tư duy sáng tạo đã
từng bước được tự động hóa. Nhiều hệ chuyên gia thuộc các lĩnh vực khác nhau như giáo
dục, y tế, pháp luật... đã được xây dựng nhằm thỏa mãn nhu cầu con người. Tuy nhiên, số
lượng những sản phẩm phục vụ cho quản lý dự án phần mềm lại không nhiều. Phần lớn các
công cụ hỗ trợ hiện nay như Microsoft Project, Rational Rose, Source Safe. . . chỉ giải quyết
được những vấn đề thuộc về biểu diễn nghiệp vụ và lưu trữ thống kê. Những yêu cầu đòi hỏi
khả năng thông minh và năng lực suy luận cao vẫn do con người đảm nhận.
Từ những thực tế trên, nhiệm vụ đặt ra đối với đề tài luận văn là nghiên cứu xây dựng
một mô hình hệ chuyên gia hỗ trợ ước lượng dự án phần mềm một cách tương đối chính xác,
đáp ứng được những đòi hỏi trong thực tế. Trên cơ sở đó, luận văn cũng tiến hành cài đặt thử
nghiệm một chương trình, cho phép ước lượng tự động các dự án phần mềm. Hướng tiếp cận
được đề xuất trong đề tài là dựa trên mô hình lập luận theo tình huống (Case based reasoning
- CBR). Theo hướng tiếp cận này, chi phí cho một dự án được ước lượng bằng cách tìm kiếm
các dự án tương tự đã hoàn thành trong quá khứ và hiệu chỉnh kết quả các dự án đó để phù
hợp với ngữ cảnh của dự án mới. Mô hình này tương đối gần với phương pháp ước lượng mà
chúng ta vẫn thường thấy ở các chuyên gia.
Công việc ước lượng nhằm thực hiện các mục tiêu:


11/71


Dự toán ngân sách



Xác định điểm hòa vốn và phân tích rủi ro



Lập kế hoạch và điều phối dự án



Phân tích tình hình đầu tư

Đối với người quản trị dự án, có nhiều đại lượng chưa biết cần được ước lượng.
Các đại lượng này thường nằm trong các lĩnh vực:


Chi phí phát triển dự án



Lịch trình phát triển dự án



Quy mô đội phát triển



Khối lượng phần mềm cần phát triển



Yêu cầu tài nguyên phần cứng

Tuy nhiên, không giống như việc ước lượng các đại lượng hữu hình (sản phẩm công
nghiệp, công trình xây dựng. . . ), ước lượng phần mềm là một công việc rất khó khăn. Các dự
án chỉ có thể ước lượng một cách tương đối chính xác khi đi về các pha phát triển sau. Điều
này hoàn toàn không có ý nghĩa nếu mục đích của ước lượng là làm căn cứ để lập kế hoạch.
Thực tế đã chứng minh rằng có tới 15% các dự án đã phải bỏ dở do chi phí phát triển vượt xa
ước lượng ban đầu.
Nguyên nhân của tình trạng trên là do đặc thù của phần mềm là một sản phẩm trí tuệ
vô hình, không thể đo được một cách trực tiếp. Các số liệu thu được thường rất phức tạp và
không thể hiện được mọi đặc trưng của phần mềm. Hơn nữa, với sự biến đổi nhanh của công
nghệ, việc dự đoán trước để đưa ra một chuẩn chung đánh giá mọi phần mềm là rất khó khăn.
Chính vì vậy, chúng ta không thể áp dụng những phương pháp ước lượng công nghiệp truyền
thống cho lĩnh vực công nghệ phần mềm.
1.3 Các phƣơng pháp ƣớc lƣợng
Trải qua 60 năm phần mềm tồn tại và được phát triển, đã có nhiều mô hình và phương
pháp ước lượng được đưa ra nhằm ước lượng chính xác được chi phí cũng như thời gian thực
hiện dự án. Mỗi phương pháp đều có ưu và nhược điểm và hầu hết chỉ áp dụng được trong
một số trường hợp ngữ cảnh cụ thể.


12/71
Các phương pháp ước lượng được phân loại thành sáu nhóm chính [4] như Hình 1

Hình 1 Các kỹ thuật ước lượng theo giai đoạn


Mô hình cơ bản trong ước lượng chi phí

phần mềm : o Putnam‟s Software Life-cycle

Model (SLIM) o CHECKPOINT
o

PRICE-S

o ESTIMACS
o SEER-SEM
o SELECT Estimator
o COCOMO
 Kỹ thuật ước lượng cải tiến
o DELPHI
o Work breakdown structure (WBS)
 Ước lượng với hệ chuyên gia
o Case Based Reasoning (CBR)
o Neural Networks
 Kỹ thuật ước lượng động
 Kỹ thuật ước lượng hồi quy
o Ordinary Least Squares (OLS)
o Hồi quy Robust
 Kỹ thuật kết hợp


13/71
o

Bayesian

1.3.1 Các mô hình ƣớc lƣợng cơ bản
1.3.1.1 Putnam’s Software Life-cycle Model (SLIM)
Mô hình SLIM [4] được đề xuất dựa trên những phân tích của Putnam, sử dụng phân

phối Rayleigh về quan hệ giữa số lượng nhân lực và thời gian phát triển của dự án trong vòng
đời phát triển (Hình 2). Công thức ước lượng mức vĩ mô là :
Ss  Ck K 1/ 3td4 / 3

Trong đó:
o

Ss : số lượng dòng mã lệnh nguồn

o

K : nỗ lực trong vòng đời, tính bằng người-năm (man-years)

o

td : thời gian phát triển tính bằng năm

o

Ck : một “hằng số kỹ thuật”

Giá trị của C thường nằm trong khoảng từ 57.314 đến 610. Phiên bản SLIM mới cho
phép tính Ck dựa trên các dự án trong quá khứ hoặc xem nó dưới dạng một hàm của các nhân
tố của dự án như ngôn ngữ lập trình, ràng buộc phần cứng, kinh nghiệm phát triển, quy trình
quản lý. . .Đối với hệ thống lớn, nỗ lực phát triển DE 1 được ước lượng theo mô hình SLIM sẽ
xấp xỉ bằng 40% nỗ lực phát triển trong cả vòng đời. Đối với những hệ thống nhỏ hơn, tỉ lệ
này sẽ thay đổi và là một hàm của kích thước hệ thống.
Mô hình SLIM (Hình 2) cũng có thể mở rộng để ước lượng những yếu tố định lượng
khác như sự phân bổ nhân lực, chu kỳ vốn, các mốc lịch biểu chính, các mức độ tin cậy, chi
phí tính toán và các chi phí cho tài liệu.

1

Development Effort


14/71

Hình 2 Phân phối Rayleigh cho nỗ lực phát triển [4]
Điểm thú vị nhất của mô hình SLIM là nó cho thấy mối quan hệ giữa nỗ lực phát triển
K và thời gian phát triển td. Đối với một hệ thống có kích thước cho trước, từ phương trình 1
chúng ta có:
K

Như vậy là nỗ lực phát triển là đại lượng rất phi tuyến đối với thời gian
phát triển. Để giảm thời giản phát triển đi 1/2 thì phải tăng nỗ lực lên gấp 16 lần.
Ngoài ra, mô hình SLIM cũng đưa ra một số công cụ ước lượng các yếu tố bên trong
của dự án như đường cong phân phối Rayleigh cho các nỗ lực phát triển một lần, ước lượng
rủi ro và độ bất định, ước lượng thời gian phát triển tối thiểu cho dự án có nỗ lực phát triển bị
ràng buộc trước.
1.3.1.2 Checkpoint
Checkpoint là công cụ hỗ trợ ước lượng được phát triển năm 1997. Nó có cơ sở dữ liệu
bao gồm 8000 dự án phần mềm và tập trung vào bốn mảng cần thiết để quản lý nâng cao chất
lượng và hiệu quả sản xuất. Nó sử dụng các đặc tính chức năng là đầu vào chính để tính kích
thước dự án.


15/71
Ước lượng : dự kiến nỗ lực ở 4 mức chính gồm dự án, pha phát triển, hoạt động, và
các đầu công việc. Ước lượng bao gồm cả nhân lực, sản phẩm bàn giao, các lỗi dự kiến, chi

phí và kế hoạch.
Đo lường : kiểm soát đưa ra những số liệu chỉ tiêu của dự án nhắm phân tích, đưa ra
những bài học kinh nghiệm và phát triển tri thức để ước lượng nội bộ.
Đánh giá : đánh giá quá trình thực hiện để so sánh con số thực tế với số liệu dự kiến.
Kiểm soát còn đánh giá được những ưu và nhược điểm của môi trường phát triển phần mềm.
Những đề xuất cải tiến quy trinh có thể được ghi nhận lại và quyết định giá cả cũng như lợi
nhuận trong quá trình thực thi.
1.3.1.3 PRICE-S
Mô hình PRICE-S [4] được bắt đầu được phát triển nhằm sử dụng nội bộ trong dự án
phần mềm thuộc chương trình Apollo moon. Phát hành năm 1977 như là mô hình độc quyền
và sử dụng trong ước lượng cho US DoD, NASA và những dự án phần mềm của chính phủ.
Toàn bộ công thức tính không được công bố tuy nhiên một vài công thức được công bố vào
năm 1988. Mô hình ước lượng Price-s bao gồm 3 mảng chính có thể ước lượng được là giá
thành, kế hoạch phát triển và kế hoạch hỗ trợ hệ thống máy tính.
1.3.1.4 ESTIMACS
Mô hình ESTIMAC2 [4], được Howard Rubin đưa ra vào năm 1983 dựa trên mô hình
Quest. Đây là một mô hình “vĩ mô” đề cập khá đầy đủ đến các khía cạnh của dự án (cả phần
cứng lẫn phần mềm). Tuy nhiên, mô hình nguyên thủy chỉ chủ yếu tập trung vào pha phát
triển mà chưa đề cập đến pha bảo trì.
Rubin đề ra 6 chiều ước lượng và một ánh xạ thể hiện quan hệ giữa chúng. Đối với
từng chiều ước lượng Rubin định nghĩa những nhân tố, gọi là nhân tố dự án, để đặc tả tổng
thể dự án. Dữ liệu cho các nhân tố này được thu thập thông qua một bảng các câu hỏi được
soạn sẵn.
Mô hình ESTIMACS được chia làm 5 mô hình con:

2

o

Ước lượng nỗ lực phát triển

o

Ước lượng nhân lực và chi phí

mô hình này được phát triển dưới sự tài trợ của Management and Computer Services - MACS


16/71
o

Ước lượng cấu hình phần cứng

o

Ước lượng rủi ro

o

Phân tích tình hình vốn

Chi tiết về các phương pháp ước lượng cho từng mô hình không được công bố do
ESTIMACS là sản phẩm thương mại. Tuy nhiên, về cơ bản ước lượng này là một hàm của
các nhân tố dự án, trong đó đầu ra của mô hình con này có thể là đầu vào của con mô hình
kia.
1.3.1.5 SEER-SEM
SEER-SEM là sản phẩm được đề xuất bởi Galorath, hội liên hiệp El Segundo,
California [4]. Mô hình này dựa trên mô hình Jensen gốc đã được đưa ra thị trường trong
khoảng 15 năm. Trong suốt thời gian này nó được phát triển thành công cụ hữu dụng trong
phương pháp ước lượng từ trên xuống và từ dưới lên. Phạm vi của mô hình rất rộng. Nó bao

gồm tất cả các pha của vòng đời phát triển phần mềm, từ giai đoạn khởi tạo ban đầu tới thiết
kế, phát triển, triển khai và bảo trì. Nó bao gồm những biến môi trường và tham số cấu hình
ứng dụng. Mô hình này sử dụng ước lượng trên cả phương thức và ngôn ngữ. Những cách
thức phát triển bao gồm hướng đối tượng, tái sử dụng, COTS, lặp, thác nước, mẫu thử và phát
triển tăng dần. Ngôn ngữ phát triển đời thứ 3 hoặc 4 như C++, FORTRAN, COBOL, Ada…
Nó cũng cho phép việc nhập những yêu cầu thiết kế, chuẩn quy trình và rủi ro có thể có như
là những ràng buộc của quá trình ước lượng.
Hình 3 thể hiện đầu vào và đầu ra của hệ thống ước lượng

Hình 3 Đầu vào và đầu ra của mô hình ước lượng SEER-SEM


17/71
Các chức năng của mô hình SEER-SEM


Cho phép ước lượng theo các mức độ, ràng buộc về ép tiến độ và kế

hoạch thực hiện được đưa vào như là những biến độc lập.

vào.

Hỗ trợ việc mở rộng phạm vi và phân tích để cân đối những tham số đầu



Tổ chức những thành phần dự án theo cấu trúc WBS3



Hiển thị quá trình ước lượng dự án



Cho phép tương tác với các thành phần kế hoạch của dự án trên biểu đồ

phân cấp Gantt,


Thực hiện ước lượng trên những dữ liệu của các dự án đã tồn tại.

Mô hình có những đặc điểm chính sau :
Tham số : kích thức, nhân sự, độ phức tạp, môi trường và ràng buộc – mỗi thuộc tính
có nhiều tham số độc lập ; tập danh sách các platform và ứng dụng, những phương thức phát
triển, chuẩn tương thích, kinh nghiệp của người sử dụng.
Kết quả ước lượng : nỗ lực, kế hoạch, số lượng nhân sự, số lỗi và chi phí ; thông số
ước lượng thời gian, nhân sự và nỗ lực là ràng buộc với nhau.
Phân tích rủi ro : phân tích có thể là ít nhất hoặc gần giống với giá trị của các tham số
đầu ra ; có thể điều chỉnh các thành phần riêng biệt của WBS, cho phép sắp xếp các thành
phần ước lượng theo mức độ quan trọng.
Phương thức ước lượng độ lớn dự án : theo hướng chức năng, cả
Đầu ra và giao diện : có nhiều chỉ tiêu, hàng trăm báo cáo và biểu đồ, phân tích các
yêu tố để so sánh điều chỉnh ; có khả năng tích hợp với các hệ thống ứng dụng Windows
khác.
1.3.1.6 Mô hình COCOMO
Mô hình ước lượng COCOMO4 [5] được Boehm đề xuất vào năm 1981, là một trong
những mô hình phổ biến nhất trong thập kỷ 80. Mô hình này ước lượng dựa trên kích thước
dự án. Ưu điểm nổi bật của mô hình này là đã hình thức hóa được các nhân tố trong một dự
án phần mềm để từ đó làm căn cứ xây dựng một mô hình ước lượng khách quan.
3

4

WBS_ Work breakdown structures
COntractive COst MOdel


18/71
Phương trình COCOMO tổng quát có dạng như sau:
Effort  C1 EAF  (Size) P1
Time  C2  (Effort ) P2

(3)
(4)

Trong đó:
o

Effort: nỗ lực tính bằng staff-months

o

C1: hằng số tỉ lệ cho nỗ lực

o

EAF5: hệ số hiệu chính phụ thuộc vào miền bài toán, nhân tố con người,

môi trường, công cụ phát triển v.v.
o

Size: kích thước của sản phẩm cuối tính bằng số dòng mã lệnh (LOC-

Line Of Code)
o

P1: thừa số mũ biểu hiện khả năng tiết kiệm chi phí (tái sử dụng, năng

lực quản lý . . . )
o

Time: thời gian tính bằng tháng

o

C2: hệ số tỷ lệ cho lịch biểu

o

P2: số mũ biểu thị sự khả năng tận dụng thời gian (phát triển song song)

Mô hình COCOMO nguyên thủy được xây dựng dựa trên dữ liệu từ 56 dự án, trong đó
Boehm đã chia các phần mềm thành 3 mode là:


Mode tổ chức: gồm những dự án trong nội bộ tổ chức, độ phức tạp thấp

và có quy trình phát triển linh hoạt. Các yêu cầu chức năng, chất lượng, giá
thành và lịch trình có thể thay đổi linh hoạt mà không ảnh hưởng tới lớn chi phí
chung.


Mode nhúng: gồm những phần mềm nhúng, không hoạt động độc lập.

Các yêu cầu về độ phức tạp, độ tinh cậy, và tính ổn định trong phát triển là rất
cao.


Mode nửa gắn: là một mode trung gian giữa hai mode trên.

Công thức ước lượng cho cả 3 mode đều có dạng 1.3 và 1.4, chỉ sai khác nhau về các
hệ số C1, C2, P1, P2 (xem bảng 1)
Bảng 1 Hệ số các mode trong mô hình COCOMO


5

Effort Adjustment Factor


19/71
MODE
Tổ chức
Nửa gắn
Nhúng

Hệ số hiệu chỉnh EAF8 là sự tổng hợp các nhân tố đặc trưng cho từng dự án cụ thể.
Các nhân tố này được tham số và chuẩn hóa dựa trên cơ sở dữ liệu COCOMO. Hệ số hiệu
chính EAF được tính là tích tất cả các tham số đó.
n

EAF   Attri  wi
i 1

Trong đó
-

Attri là giá trị tham số

-

wi là trọng số biểu thị vai trò của tham số trong dự án

Trong mô hình COCOMO, Boehm đã đưa ra 15 tham số hiệu chỉnh. Các tham số này
tùy vào từng dự án sẽ nhận giá trị khác nhau (very low, low, nominal, high, very high) tương
ứng các số nằm trong khoảng từ 0.5-1.5 (Bảng 2).
1.3.1.7 Mô hình COCOMO II
COCOMO là một mô hình ước lượng phổ biến vào những năm 80 [4]. Tuy nhiên, mô
hình này chỉ thích hợp với chu trình phát triển thác nước truyền thống. Đối với những chu
trình phát triển lặp hiện đại như bản mẫu, xoắn ốc, COCOMO không đáp ứng được. Năm
1995, Boehm cùng các đồng sự ở trung tâm công nghệ phần mềm USC đã cải tiến COCOMO
và đưa ra phiên bản mới là mô hình COCOMO II. Mô hình này đã tính đến các vấn đề trong
phát triển phần mềm hiện đại như phát triển không tuần tự, mô hình phát triển nhanh, tái kỹ
nghệ, tái sử dụng, phương pháp hướng đối tượng…
Bảng 2 Các tham số hiệu chỉnh trong mô hình COCOMO
Tên
RELY
DATA
CPLX
TIME

Giả
Mức độ ổn định
Kích thước CSDL
Độ phức tạp
Ràng buộc thời g


20/71
STOR

Ràng buộc lưu tr

VIRT

Độ ổn định của m

TURN

Thời gian khôi ph

ACAP

Năng lực phân tíc

AXEP

Kinh nghiệm đối

PCAP

Năng lực lập trìn

VEXP

Kinh nghiệm đối

LEXP

Kinh nghiệm dùn

Ứng dụng phươn

MODP

hiện đại

TOOL

Ứng dụng công c

SCED

Yêu cầu lịch trình

Chiến lược của COCOMO II là :


Giữ được tính mở trong COCOMO nguyên thủy



Xây dựng COCOMO phù hợp với yêu cầu của thị trường


Xây dựng những chiến lược ước lượng khác nhau đối với từng giai đoạn
của dự
án


Các thông số đầu vào và đầu ra phải phù hợp yêu cầu thực tế

Điểm cải tiến lớn nhất trong COCOMO II là không coi các đặc tả yêu cầu, kế
hoạch . . . là những yếu tố bất biến. Do đó ước lượng tùy từng giai đoạn khác nhau sẽ có giá
trị khác nhau với độ tin cậy khác nhau. Mô hình COCOMO gồm 3 mô hình con, tương ứng
với ba giai đoạn phát triển của dự án: (1) mô hình kết cấu, (2) mô hình tiền thiết kế, (3) mô
hình hậu kiến trúc6.
Mô hình kết cấu
Tương ứng với giai đoạn bắt đầu thực hiện dự án. Trong giai đoạn này yêu cầu vẫn
chưa rõ ràng và ổn định, các giá trị đầu vào chưa cụ thể và kiến trúc hệ thống chỉ ở mức kết


cấu (mức khái niệm). Ước lượng trong giai đoạn này có độ tin cậy không cao và chỉ nhằm
mục đích tránh những rủi ro nghiêm trọng sau này. Công thức chung cho mô hình kết cấu là:

6

(1) Application composition model, (2) Early Design Model, (3) Post-architecture model


21/71

Effort 

Trong đó:
o

Effort là nỗ lực ước lượng

o

NOP là số lương điểm đối tượng (Number of Object Points)

o

PROD là năng suất lao động

Mô hình tiền tiền thiết kế
Tương ứng với giai đoạn đã nắm được rõ ràng các yêu cầu và bắt đầu bước vào thiết
kế. Đây là giai đoạn thống nhất giữa yêu cầu, kiến trúc hệ thống và lịch trình phát triển. Công
thức ước lượng của mô hình này cũng có dạng tương tự như mô hình COCOMO truyền thống
nhưng đã được đơn giản hóa:
Effort  2.45  EArch  (size) P

Trong đó:
o

Effort là nỗ lực ước lượng

o

EArch là hệ số hiệu chỉnh

o

Size là kích thước tính bằng LOC hoặc điểm chức năng

o

P là hệ số mũ của quy trình phát triển

Trong mô hình này, giá trị 2.45 thu được thông qua thống kê dữ liệu của các dự án đã
có. Hệ số hiệu chỉnh EArch được tính là tích của 7 thừa số hiệu chỉnh cho trong bảng 2. Mô
hình tiền thiết kế đã đơn giản hóa việc xác định tham số vì thực tế tại giai đoạn này vẫn còn
rất nhiều thông tin vẫn chưa được làm rõ.
Bảng 3 Tham số hiệu chỉnh trong mô hình tiền thiết kế
Tên
RCPX

RELY-DAT

RUSE

RUSE

PDIF

TIME-STO