Các kỹ thuật đánh giá công sức và nguồn lực trong quản lý dự án phần mềm sử dụng hướng tiếp cận điểm chức năng sử dụng UCP

BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
------------------------------------------

Chu Xuân Bảo
CÁC KỸ THUẬT ĐÁNH GIÁ CÔNG SỨC VÀ NGUỒN LỰC
TRONG QUẢN LÝ DỰ ÁN PHẦN MỀM SỬ DỤNG HƯỚNG
TIẾP CẬN ĐIỂM CHỨC NĂNG SỬ DỤNG UCP
LUẬN VĂN THẠC SỸ
NGÀNH: CÔNG NGHỆ THÔNG

TIN

NGƯỜI HƯỚNG DẪN: HUỲNH QUYẾT THẮNG

Hà Nội – 2013


MỤC LỤC
MỤC LỤC

1

DANH MỤC CÁC BẢNG

4

DANH MỤC HÌNH VẼ

5

DANH SÁCH CÁC TỪ VIẾT TẮT

6

MỞ ĐẦU

7

1. Cơ sở khoa học và thực tiễn của đề tài:

7

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

7

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

7

4. Nội dung luận văn:

8

CHƯƠNG 1:TỔNG QUAN CÔNG TÁC ĐÁNH GIÁ CÔNG SỨC
TRONG QUẢN LÝ DỰ ÁN PHẦN MỀM
1.1. Đánh giá cơng sức phần mềm là gì
1.2. Các bước cơ bản trong đánh giá cơng sức phần mềm

9

9
11

1.2.1. Đánh giá kích cỡ của phần mềm

12

1.2.2. Đánh giá nỗ lực

13

1.2.3. Đánh giá lịch trình

15

1.2.4. Đánh giá về chi phí

16

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

17

1.3.1. Phương pháp phân tích Điểm Chức năng nghiệp vụ

18

1.3.2. Mơ hình đánh giá giá cấu thành (COCOMO)

23

1.3.3. phương pháp đánh giá công sức dự án theo Use Case

28

1.4. Kết chương

33

Chương 2: PHƯƠNG PHÁP ĐÁNH GIÁ CÔNG SỨC PHẦN MỀM SỬ
DỤNG HƯỚNG TIẾP CẬN ĐIỂM CHỨC NĂNG SỬ DỤNG

35

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

35

2.1.1. Các khái niệm

37

2.1.2. Phương pháp xác định Tác nhân và Use Case

42

2.1.3. Quan hệ giữa các Use Case

47

1


2.1.4. Miêu tả Use Case

48

2.1.5. Thử Use Case

52

2.1.6. Thực hiện các Use Case

53

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

55

2.2.1. Tổng quát về xác định giá trị phần mềm

55

2.2.2. Tính số điểm Use Case sau hiệu chỉnh (AUCP)

56

2.2.3. Đánh giá nỗ lực từ số Use Case

70

2.2.4. Tổng hợp giá trị phần mềm

71

2.3. Kết chương

72

Chương 3: XÂY DỰNG CÔNG CỤ HỖ TRỢ XÁC ĐỊNH GIÁ TRỊ PHẦN
MỀM BẰNG PHƯƠNG PHÁP USE CASE

73

3.1. Phát biểu bài tốn

73

3.2. Phân tích bài tốn

73

3.2.1. Phân tích tổng thể

73

3.2.2. Phân tích cụ thể chức năng

73

3.3. Đặc tả chương trình

74

3.3.1. Biểu đồ Use Case của chương trình

74

3.3.2. Các biểu đồ hoạt động

75

3.4. Thiết kế logic hoạt động cho chương trình

77

3.4.1. Xác định các lớp phân tích

77

3.4.2. Các biểu đồ cộng tác

77

3.4.3. Các biểu đồ tuần tự

78

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

80

3.5.1. Phân tích bài tốn để xây dựng cơ sở dữ liệu

80

3.5.2. Xây dựng biểu dồ thực thể - liên kết (E-R)

81

3.5.3. Xây dựng lược đồ quan hệ

84

3.6. Kết chương

85

Chương 4:THỬ NGHIỆM ÁP DỤNG TRONG DỰ ÁN XÂY DỰNG PHỊNG
MƠ PHỎNG ĐIỀU KHIỂN TÀU BIỂN

2

86


4.1. Đánh giá công sức phần mềm dự án xây dựng phịng mơ phỏng ĐKTB

86

4.1.1. Sắp xếp thứ tự ưu tiên các yêu cầu chức năng phần mềm

87

4.1.2. Chuyển đổi yêu cầu chức năng sang USE-CASE

94

4.2. Đánh giá quy trình tính tốn

103

4.2.1. So sánh UCP với FPA

104

4.2.2. So sánh UCP với COCOMO

105

4.3. Kết chương

105

KẾT LUẬN

107

TÀI LIỆU THAM KHẢO

110

3


DANH MỤC CÁC BẢNG
Bảng 1- 1. Tính UFPs – kích cỡ xử lý thông tin thô – trong FPA ............................19
Bảng 1- 2. Mười bốn Yếu tố kĩ thuật trong FPA ......................................................20
Bảng 1- 3. Phân loại chế độ phát triển sản phẩm trong COCOMO cơ sở ................24
Bảng 1- 4. Các Yếu tố điều chỉnh trong COCOMO trung cấp .................................26
Bảng 1- 5. Phân loại chế độ phát triển trong COCOMO trung cấp ..........................27
Bảng 2- 1. Sắp xếp chức năng phần mềm .................................................................59
Bảng 2- 2. Phân loại và đánh trọng số điểm Use Case trong UCP ...........................61
Bảng 2- 3. Ví dụ đếm số Use Case sau khi đánh trọng số ........................................62
Bảng 2- 4. Phân loại và đánh trọng số tác nhân trong UCP......................................63
Bảng 2- 5. Ví dụ đếm số tác nhân sau khi đánh trọng số ..........................................64
Bảng 2- 6. Trọng số của 13 yếu tố kĩ thuật trong UCP ............................................66
Bảng 2- 7. Ví dụ tính Yếu tố Độ phức tạp Kĩ thuật trong UCP ................................67
Bảng 2- 8. Trọng số của 8 yếu tố mơi trường trong UCP .........................................68
Bảng 2- 9. Ví dụ tính Yếu tố Độ phức tạp Môi trường trong UCP ..........................69
Bảng 2- 10. Tổng hợp đánh giá giá trị phần mềm ....................................................72
Bảng 3- 1. Kịch bản Use Case “Thực hiện ước lượng mới” ....................................75
Bảng 3- 2. Kịch bản Use Case“Tìm kiếm đánh giá lịch sử” ....................................75
Bảng 4- 1. Sắp xếp chức năng phần mềm .................................................................93
Bảng 4- 2. Bảng chuyển từ chức năng sang Use Case ..............................................98
Bảng 4- 3. Tính tốn điểm các tác nhân trao đổi thông tin với phần mềm ...............99
Bảng 4- 4. Tính tốn điểm các trưởng hợp sử dụng................................................100
Bảng 4- 5. Tính tốn hệ số phức tạp kỹ thuật cơng nghệ ........................................101
Bảng 4- 6. Tính tốn hệ số tác động mơi trường và nhóm làm việc .......................102
Bảng 4- 7. Tổng hợp tính tốn tổng giá trị phần mềm ............................................103

4


DANH MỤC HÌNH VẼ
Hình 1. 1 Đồ thị hội tụ đánh giá. Độ chính xác của đánh giá cơng sức phần mềm chỉ
được cải tiến chính trong q trình phát triển ...........................................................10
Hình 1-2. Tiến trình cơ sở đánh giá cơng sức phần mềm của dự án.........................17
Hình 2. 1 Một ví dụ biểu đồ Use case .......................................................................38
Hình 2. 2- biểu tượng tác nhân trong UML ..............................................................41
Hình 2. 3– Các Use case trong hệ thống điều khiển máy tàu ...................................46
Hình 3. 1 Biểu đồ Use Case tổng thể - UCPEstimation ............................................74
Hình 3. 2 Biểu đồ hoạt động của Use Case"Thực hiện đánh giá mới dự án" ...........76
Hình 3. 3 Biểu đồ hoạt động của Use Case"Tìm kiếm đánh giá lịch sử" .................76
Hình 3. 4. Biểu đồ cộng tác cho Use Case"Thực hiện dánh giá mới" .....................77
Hình 3. 5. Biểu đồ cộng tác cho Use Case"Tìm kiếm đánh giá lịch sử" ..................78
Hình 3. 6 Biểu đồ tuần tự cho Use Case"Thực hiện đánh giá mới" .........................79
Hình 3. 7. Biểu đồ tuần tự cho Use Case"Tìm kiếm đánh giá lịch sử" .....................80
Hình 3. 8. Biểu đồ thực thể - liên kết ........................................................................82
Hình 3. 9. Biểu đồ thực thể-mối quan hệ - UPC Estimator .....................................83
Hình 4. 1. Hình vẽ phối cảnh cabin chính tổ hợp mô phỏng ....................................86

5


DANH SÁCH CÁC TỪ VIẾT TẮT
COCOMO

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

EAF

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

ER

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

FP

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

UFP

: Unadjusted Function Point – Điểm Chức năng chưa được điều chỉnh

FPA

: Function Point Analysis – Phân tích điểm chức năng

FPs

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

UCP

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

UCPs

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

UML

: Unified Modelling Language – ngôn ngữ mơ hình hóa thống nhất

AUCP

: Adjusted Use Case Point - Điểm chức năng sử dụng sau hiệu chỉnh

UUCP

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

UUCPs

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

TAW

: Total Actors Weighted– Tổng số Tác nhân sau khi đánh trọng số

TBW

: Tổng số chức năng sử dụng sau khi đánh trọng số

TCF

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

ECF

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

6


MỞ ĐẦU
1. Cơ sở khoa học và thực tiễn của đề tài:
Công sức phần mềm liên quan đến cả thời gian và nguồn lực phải bỏ ra trong
quá trình phát triển phần mềm. Việc dự báo, đánh giá công sức phần mềm là một
hoạt động mang tính quyết định đối với sự khả thi của dự án phần mềm, chỉ ra
phương án điều khiển thời gian và ngân quỹ trong suốt quy trình phát triển phần
mềm.
Các phương pháp truyền thống thường là không tin cậy hoặc là yêu cầu quá
nhiều các thao tác đo, tính tốn phức tạp. Hơn nữa, do bộ dữ liệu thử nghiệm q
nhỏ khơng mang tính đại diện dẫn đến kết quả khơng chính xác.
Việc nghiên cứu, hoàn thiện các phương pháp dự báo và đánh giá cơng sức
phần mềm mang tính thực tiễn cao và có ý nghĩa rất lớn trong quản lý các dự án
phần mềm.
2. Mục đích của đề tài :
Nghiên cứu và kế thừa một số phương pháp dự báo, đánh giá công sức,
nguồn lực trong quản lý dự án phần mềm ở Việt Nam và trên thế giới. Tập hợp và
phân tích các đặc điểm của các phương pháp định giá sản phẩm phần mềm. Lựa
chọn phương pháp điểm chức năng sử dụng (Use Case Point) để đánh giá công sức
dự án phần mềm, thực hiện các thử nghiệm đối với một dự án phần mềm đã có, thử
nghiệm và đánh giá thực tế việc sử dụng phương pháp trong tính toán các dự án
phần mềm ở Học Viện Hải Quân.

3. Các vấn đề cần giải quyết của đề tài:
Đề tài tập trung giải quyết các vấn đề sau
3.1 Nghiên cứu cơ sở lý thuyết và nền công nghệ cơ bản phục vụ nhiệm vụ
đề tài.

7


Nghiên cứu các cơ sở lý thuyết và các công nghệ có liên quan đến việc dự báo, đánh
giá cơng sức, nguồn lực phần mềm đã và đang được nghiên cứu ứng dụng.
3.2. Tiến hành So sánh, lựa chọn mô hình đánh giá, dự đốn cơng sức phần
mềm. Nghiên cứu, so sánh, phân tích đánh giá các mơ hình truyền thống, các mơ
hình hiện có. Phân tích đánh giá cơng sức phần mềm trong các phương pháp phát
triển phần mềm đã biết, từ đó, lựa chọn mơ hình phù hợp để ứng dụng. Tập trung
vào phương pháp đánh giá điểm chức năng Use-Case Point (UCP)
3.3. Học tập các mơ hình thông dụng, thử nghiệm, hiệu chỉnh các thông số
và thống kê kết quả thực hiện tiến trình trên mơ hình, kết luận về tính khả thi, độ
chính xác và ưu, nhược điểm của các thông số áp dụng trên mô hình đã chọn.
3.4. Áp dụng, thử nghiệm đánh giá tại một số phần mềm và dự án triển khai
tại Trung tâm huấn luyện Mô phỏng – Học viện Hải quân.
4. Nội dung luận văn:
Với các phân tích và yêu cầu nêu trên, luận văn bao gồm các phần sau:
Mở đầu
Chương 1 : Tổng quan về đánh giá công sức và nguồn lực trong quản lý Dự
án phần mềm
Chương 2 : Phương pháp điểm chức năng UCP (Use Case Point)
Chương 3 : Xây dựng công cụ hỗ trợ phương pháp điểm chức năng UCP
Chương 4: Thử nghiệm áp dụng trong Dự án Xây dựng phịng mơ phỏng
điều khiển tàu biển.
Kết luận

Trong quá trình thực hiện Luận văn, do thời gian cũng như trình độ cịn hạn
chế nên khơng thể tránh khỏi những thiếu sót. Rất mong nhận được sự góp ý của
các thầy, cô giáo và các bạn để Luận văn hồn thiện hơn. Tơi xin chân thành cảm
ơn sự hướng dẫn, giúp đỡ tận tình của thầy hướng dẫn, PGS.TS Huỳnh Quyết
Thắng, các thầy trong viện công nghệ thông tin và truyền thông – Đại học Bách
khoa Hà Nội đã giúp đỡ tơi trong q trình học tập cũng như trong quá trình làm
Luận văn.

8


CHƯƠNG 1
TỔNG QUAN CÔNG TÁC ĐÁNH GIÁ CÔNG SỨC
TRONG QUẢN LÝ DỰ ÁN PHẦN MỀM
1.1. Đánh giá công sức phần mềm là gì
Trong quản lý dự án phần mềm, việc đánh giá công sức phần mềm hiệu quả
là một hoạt động quan trọng, đồng thời cũng là một thách thức trong phát triển phần
mềm. Đánh giá công sức phần mềm là một trong những nền tảng cho việc lập lịch
dự án một cách hiệu quả: Sẽ không thể lập được kế hoạch và điều khiển dự án có
hiệu quả nếu khơng có một qui trình tính tốn cơng sức phần mềm đầy đủ và đáng
tin cậy. Khi đó, cùng với việc phải chịu các tác động tài chính, bị mất lợi thế cạnh
tranh, và chậm trễ trong việc hưởng lợi từ kế hoạch và các sáng kiến là hậu quả của
việc áp dụng một qui trình tính tốn cơng sức khơng đầy đủ, thiếu chính xác và
khoa học.
Cho đến bây giờ cũng dễ nhận thấy rằng ngành công nghiệp phần mềm nói
chung khơng có nhiều các phương pháp tốt để đánh giá cơng sức phần mềm của dự
án. Hình 1-1, tham khảo từ tài liệu ([6] McConnell, 1996) thể hiện độ hội tụ của
đánh giá công sức phần mềm trong vòng đời phát triển dự án của các dự án thực tế,
việc đánh giá chỉ được chính xác hóa dần dần trong quá trình làm mịn dần dự án.
Từ hình vẽ có thế nhận thấy rằng để đưa ra được các đánh giá đáng tin cậy và sớm

trong vòng đời phát triển của dự án là rất khó. Chúng ta phải chịu nhiều thiệt hại
hơn như là một hậu quả, do đó, chúng ta cần tập trung nhiều nỗ lực để giải quyết
tình hình
Đánh giá khơng đầy đủ cơng sức phần mềm của một dự án dẫn đến
(a) việc bố trí thiếu cho dự án (điều mà thường dẫn đến việc vượt quá khả
năng làm việc),
(b) quản lý thiếu các nỗ lực đảm bảo chất lượng (bỏ sót các nguy cơ rủi ro
của sản phẩm kém chất lượng), và

9


(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).
Giá dự án
(nỗ lực và kích cỡ)

Lịch trình dự án

4x

1.6

2x

1.25 x

1.5 x

1.15 x

1.25 x

1.05

1.0 x

1.0 x

0.8 x

0.9

0.67 x

0.85 x

0.5 x

0.8

0.25 x

0.6

Xác định
sản phẩm
ban đầu

Xác định

sản phẩm
được đồng ý

Đặc tả
yêu cầu

Đặc tả thiết kế
sản phẩm

Đặc tả Sản phẩm
thiết kế hồn thành
chi tiết

Hình 1. 1 Đồ thị hội tụ đánh giá. Độ chính xác của đánh giá cơng sức phần mềm
Nguồn tham khảo: ([6] McConnell. 1996)
Cịn đối với những người mà mong muốn tránh khỏi tình huống này bằng
cách thêm nhiều yếu tố thừa vào đánh giá, thì việc đánh giá thừa cơng sức của một
dự án có thể chỉ làm tồi tệ cho tổ chức. Nếu như đưa cho một dự án nhiều tài
nguyên hơn mức nó thực sự cần mà khơng có những điều hành phạm vi đầy đủ, nó
sẽ bị dùng hết. Điều này giống như là quy tắc Parkinson được mô tả trong bài viết
([10] What Is Parkinson’s Law in Project Management?, 2010): “Work expands so

10


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 để hồ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ì hỗn việc sử dụng tài ngun ở các dự án tiếp theo.
1.2. Các bước cơ bản trong đánh giá cơng sức phần mềm
Có bốn bước chính trong đánh giá công sức dự án phần mềm là:
1. Đánh giá phạm vi của sản phẩm phát triển. Thông thường, điều này ln
u cầu một kết quả đánh giá kích cỡ của phần mềm được phát triển theo số dòng
lệnh (LOC – line of code) hoặc điểm chức năng (FP – Function Point). Trong khi
kích cỡ theo LOC là đơn vị kích cỡ cơ sở được dùng bởi nhiều mơ hình tính tốn
đánh giá hàng đầu, nhiều đội phát triển lại khơng thích với những phép đo này và
dùng những đơn vị ít chính quy hơn (số đặc tính, số yêu cầu thay đổi, số trường hợp
sử dụng / số kịch bản, số tường thuật người dùng, số phát biểu yêu cầu, …). Một
thảo luận về các ưu điểm và nhược điểm của các phương pháp đo kích cỡ khác nhau
sẽ được đề cập ở phần sau.
2. Đánh giá nỗ lực theo đơn vị [người – tháng] hoặc [người – giờ] dùng một
mơ hình tính tốn liên hệ nỗ lực với cỡ của phần mềm và năng suất của đội phát
triển.
3. Đánh giá lịch trình theo lịch thời gian (tháng/tuần). Điều này có thể được
tính tốn từ nỗ lực được đánh giá và là một hàm số của kích cỡ đội phát triển. Điều
quan trọng là phải nhận thức rõ rằng đây khơng phải là một quan hệ tuyến tính và ở
một số điểm trong lịch trình dự án khơng thể rút ngắn lịch trình bằng cách thêm tài
nguyên cho việc phát triển.
4. Đánh giá chi phí dự án theo đơn vị tiền tệ. Điều này là một kết hợp của
giá nhân cơng (cái mà có thể được tính tốn từ ước lượng nỗ lực) và giá phi nhân

11


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. Đánh giá kích cỡ của phần mềm
Một đánh giá chính xác về kích cỡ của phần mềm được xây dựng là bước
đầu tiên cho một kết quả đánh giá 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 u cầu. Khơng nên để cho sự thiếu sót về đặc tả phạm vi làm cản trở
việc thực hiện ước lượng. Tài liệu đánh giá cũng không nên chốt cứng. Trong mọi
trường hợp, chúng ta phải xem xét các mức độ rủi ro và không chắc chắn trong một
đánh giá cho mọi khía cạnh và phải thực hiện lại việc đánh giá công sức phần mềm
cho dự án ngay khi có thêm thơng tin phạm vi được xác định. Nếu chúng ta thực
hiện đánh giá lại một dự án ở những pha sau của vòng đời dự án, các tài liệu thiết kế
có thể được sử dụng để cung cấp thêm thơng tin chi tiết.
Hai cách để có thể đánh giá kích cỡ sản phẩm là:
1. Cách thứ nhất: bằng phép tương tự. Nếu chúng ta đã hoàn thành một dự
án tương tự trong quá khứ và biết thông tin kích cỡ sản phẩm đã được phát triển,
chúng ta có thể đánh giá mỗi phần chính của của dự án mới như là một phép tính
phần trăm của kích cỡ của phần tương tự của dự án trước. Đánh giá kích cỡ tổng thể
của dự án mới bằng cách cộng lại các kích cỡ được đánh giá của mỗi phần.
Hoặc là, chia sản phẩm thành những phần cấu thành (các đặc tính, các trường
hợp sử dụng/ kịch bản, các yêu cầu người dùng) và đếm chúng. Một số người dùng
những phép đếm thô như là một phép đánh giá trực tiếp của kích cỡ phần mềm,
hoặc chúng ta có thể chuyển chúng thành một đơn vị đo kích cỡ chính thức mà ta
biết, theo một phép tính trung bình, bao nhiêu LOC hoặc FP mà mỗi phần này yêu
cầu trong những dự án trước.
Một người có kinh nghiệm có thể đưa ra những đánh giá kích cỡ tốt, hợp lý
bằng phép tương tự nếu sẵn có các giá trị kích cỡ chuẩn xác cho dự án trước và dự
án mới là gần giống với dự án trước.

12

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 tốn như là Điểm Chức năng (FP) chúng ta
có thể chuyển phép đếm thành một ước lượng của kích cỡ.
Các đặc tính sản phẩm ở cấp độ vĩ mơ có thể chứa số lượng các hệ thống
con, các lớp/ mơ – đun, các phương thức/ hàm. Các đặc tính sản phẩm ở mức chi
tiết hơn có thể gồm có số lượng các màn hình, các hộp thoại, các file, các bảng cơ
sở dữ liệu, các báo cáo, các thông điệp, …
1.2.2. Đánh giá nỗ lực
Một khi chúng ta có kết quả đánh giá về kích cỡ của sản phẩm, chúng ta có
thể tính tốn đánh giá nỗ lực từ nó. Việc chuyển đổi từ kích cỡ phần mềm sang nỗ
lực dự án tổng cộng chỉ có thể làm được nếu chúng ta có một vịng đời phát triển
phần mềm xác định và tiến trình phát triển mà ta sử dụng ổn định trên dự án để
phân tích, thiết kế, phát triển và kiểm thử phần mềm.
Một dự án phát triển phần mềm địi hỏi nhiều hơn cơng việc viết mã phần
mềm đơn thuần – trên thực tế, việc mã hóa chỉ chiếm chưa đến 1/2 tổng thể nỗ lực
dự án. Việc viết và thẩm định tài liệu, thi hành các bản mẫu, thiết kế các phiên bản
có thể phân phối, và thẩm định, kiểm thử mã chiếm phần lớn hơn của nỗ lực dự án
tổng thể. Đánh giá nỗ lực dự án yêu cầu ta xác định và tính tốn, sau đó tổng hợp
lại tất cả các hoạt động ta phải thực hiện để xây dựng một sản phẩm từ kích cỡ được
đánh giá.
Hai cách có thể dùng để tính tốn nỗ lực từ kích cỡ:
1. Cách thứ nhất: dùng dữ liệu lịch sử - là dùng dữ liệu lịch sử của chính tổ
chức để xác định bao nhiêu nỗ lực theo kích cỡ đã được đánh giá mà các dự án
trước dùng đến.

Một sơ đồ tính tốn mà liên hệ kích cỡ của sản phẩm và năng

suất của đội phát triển với nỗ lực dự án được đánh giá được sử dụng thường xuyên.
Dĩ nhiên, cách thức này giả định rằng :
(a) Tổ chức của chúng ta đã lập tài liệu các kết quả thực tế từ các dự án

trước;

13


(b) Chúng ta có ít nhất một dự án trong quá khứ với kích cỡ tương tự (rõ ràng
là tốt hơn nếu chúng ta có nhiều dự án với kích cỡ tương tự để củng cố rằng chúng
ta cần ổn định một mức độ nào đó của nỗ lực để phát triển các dự án của kích cỡ
được đưa ra;
(c) Chúng ta sẽ tuân theo một vòng đời phát triển tương tự, sử dụng một
phương pháp phát triển tương tự, các cơng cụ tương tự, và có một đội phát triển với
các kĩ năng và kinh nghiệm tương tự cho dự án mới.
2. Cách thứ hai: tiếp cận thuật toán - nếu chúng ta khơng có dữ liệu lịch sử
của chính tổ chức bởi vì chúng ta chưa bắt đầu thu thập số liệu hoặc vì dự án mới là
rất khỏc, Chúng ta có thể sử dụng một cách tiếp cận thuật tốn đã hồn thiện và đã
được cơng nhận rộng rãi (ví dụ mơ hình COCOMO của Barry Boehm) để chuyển
một đánh giá kích cỡ thành một đánh giá nỗ lực. Các mơ hình này có được từ việc
nghiên cứu một số lượng lớn các dự án đã hoàn thành từ nhiều tổ chức khác nhau để
xem xét các kích cỡ dự án ánh xạ như thế nào với nỗ lực dự án tổng cộng. Các mơ
hình “dữ liệu cơng nghiệp” này có thể khơng được chuẩn xác như là dữ liệu lịch sử
của chính tổ chức của chúng ta, nhưng chúng có thể cho chúng ta những đánh giá
nỗ lực gần đúng hữu ích.
Vấn đề đánh giá nỗ lực trực tiếp
Như đã đề cập, nhiều tổ chức trong nền công nhiệp phần mềm không thấy
thoải mái với khái niệm đánh giá kích cỡ sản phẩm. Khơng phải là lạ khi nhìn thấy
nỗ lực được đánh giá trực tiếp từ một mô tả của sản phẩm/dự án, bỏ qua hồn tồn
việc đánh giá kích cỡ. Trong khi điều này hồn tồn có thể làm được, nó cũng nảy
sinh vấn đề. Các đánh giá trực tiếp tới nỗ lực đã ngầm giả định năng suất của đội
phát triển cụ thể. Khi đó nếu, giống như thường thấy là, các đánh giá ban đầu khơng
theo các mục đích của chúng ta, việc làm lại các đánh giá để xem điều gì xảy ra với

những đội phát triển khác đòi hỏi việc đánh giá phải được tính lại từ đầu. Bằng cách
đánh giá kích cỡ trước chúng ta dễ dàng làm lại nhanh các đánh giá nỗ lực cho
những năng suất làm việc khác nhau của những đội phát triển khác nhau.

14


1.2.3. Đánh giá lịch trình
Bước thứ ba trong đánh giá công sức của một dự án phát triển phần mềm là
xác định lịch trình dự án từ các đánh giá nỗ lực. Điều này thường địi hỏi việc tính
tốn số lượng người sẽ làm việc trên dự án, cái gì họ sẽ làm (cấu trúc phân cấp chia
nhỏ công việc), khi nào họ sẽ bắt đầu làm việc trên dự án và khi nào họ sẽ kết thúc
(gọi là “mô tả biên chế”). Một khi chúng ta có thơng tin này, chúng ta cần tính
tốn để đưa nó vào một lịch trình theo lịch thời gian. Ngồi ra, dữ liệu lịch sử từ các
dự án trong quá khứ của tổ chức hoặc các mơ hình dữ liệu cơng nghiệp có thể được
sử dụng để dự đoán số lượng người mà chúng ta cần cho một dự án với kích cỡ cho
trước và làm thế nào cơng việc có thể chia nhỏ vào lịch trình.
Nếu chúng ta khơng có gì, một quy tắc đánh giá lịch trình ([6] McConnell,
1996) có thể được dùng để lấy một ý tưởng thô của thời gian lịch tổng cộng cần
thiết:
Lịch Trình theo Tháng = 3.0 * ( nỗ lực[người – tháng] )1/3
Thí dụ, nếu chúng ta đã đánh giá được công sức của một dự án cần nỗ lực 65
[người – tháng], biểu thức trên cho thấy rằng cần lịch trình 12 tháng (3.0 * 651/3), từ
đó suy đội dự án có 5 hoặc 6 thành viên (65 /12).
Trong ([6] McConnell. 1996) có nêu vấn đề nhiều đề xuất dùng 2.0 hay 2.5
hay ngay cả 4.0 để thay thế cho giá trị 3.0 – chỉ bằng cách dùng thử ta sẽ thấy nó
như thế nào.
Đánh giá lịch trình dự án là một chủ đề rắc rối bởi vì hầu hết các dự án
thường bị chậm trễ. Sự chậm trễ do nhiều nguyên nhân. Các yêu cầu được phát hiện
dần dần không được quản lý chủ động. Việc điều khiển chất lượng sản phẩm từ sớm

thường không được chú trọng, dẫn đến dự án sẽ bị chậm trễ khi kiểm thử bắt đầu. Ở
những tổ chức chưa có quy trình làm việc chuẩn thì những dự thảo lịch trình thường
bị bỏ qua bởi ngay từ những người điều hành cấp cao.
Xem xét công việc quản trị dự án và cơng việc đánh giá lịch trình, để ý rằng
cơng việc đánh giá lịch trình sẽ quan tâm đến việc lên lịch trình ở mức độ cao của
tồn dự án, cịn những tính tốn chi tiết hơn địi hỏi các phụ thuộc yếu tố, đội ngũ

15


nhân viên sẵn có, và mức độ tài nguyên, phân công cho từng người sẽ được thực
hiện bởi công việc quản trị dự án.
Nếu đánh giá theo biểu thức tính lịch trình ở trên, ta cần tính tốn thời gian
lịch trình trước rồi mới chỉ định số nhân viên. Nhưng nếu được chỉ định một đội
phát triển trước, một biểu thức cơ bản cho việc đánh giá lịch trình của bất kỳ hoạt
động quản lý là:
Nỗ lực / Số nhân viên = Lượng thời gian
Dùng biểu thức tổng quát này, một hoạt động mà yêu cầu 8 [người – tháng]
của nỗ lực và có 4 người được chỉ định tham gia có thể được hồn thành trong thời
gian 2 tháng.
8 [người – tháng] / 4 [người] = 2 [tháng]
Thực tế thì việc đánh giá lịch trình sẽ khó hơn rất nhiều. Nó liên quan đến nhiều yếu
tố như:
-

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

-

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

-

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

-

Số trường hợp sử dụng hệ thống làm việc mỗi ngày, số giờ làm việc hiệu quả
trong mỗi trường hợp sử dụng hệ thống

-

Những gián đoạn như là du lịch, hội nghị, đào tạo hay nghỉ ốm, …

-

Số lượng vùng thời gian cho các dự án đối với các công ty đa quốc gia
Như vậy công việc quản trị dự án và cơng việc đánh giá lịch trình có nhiều

mối liên hệ và được thực hiện theo sự tinh tế của từng người quản lý.
1.2.4. Đánh giá về chi phí
Có nhiều yếu tố để quan tâm khi đánh giá chi phí tổng cộng của một dự án.
Bao gồm giá nhân công, giá mua hay giá thuê phần cứng và phần mềm, việc đi lại
cho mục đích gặp gỡ hay kiểm thử, các giao tiếp (thí dụ, các cuộc gọi điện thoại
đường dài, hội thảo video từ xa, …), các khóa đào tạo, khơng gian văn phịng, …
Giá nhân cơng thì có thể được xác định một cách đơn giản nhất bằng phép
nhân kết quả đánh giá nỗ lực của dự án (theo giờ) với lương nhân cơng tính trung

16

bình tổng qt. 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 đánh giá như trên, đề xuất một tiến
trình cơ sở cho việc đánh giá công sức phần mềm của dự án như được mơ tả trong
sơ đồ ở Hình 1-2:
Thu thập các u cầu ban đầu

Đánh giá kích cỡ sản phẩm

Đánh giá nỗ lực

Dữ liệu dự án lịch sử

Các tài nguyên sẵn có

Đưa ra lịch trình

Dữ liệu giá hiện thời

Đánh giá chi phí

Phê duyệt kết quả đánh giá

Phát triển sản phẩm

Kết quả đánh giá được

phê duyệt

Kích cỡ, nỗ lực,chi
phí thực tế, …

Phân tích tiến trình đánh giá

Hình 1-2. Tiến trình cơ sở đánh giá công sức phần mềm của dự án.
Nguồn tham khảo: ([3] Hewson, 2007).
1.3. Một số phương pháp đánh giá công sức phần mềm
Đã có một số phương pháp được đề xuất cho việc đánh giá để hỗ trợ quản trị
dự án, trong số đó 2 phương pháp nổi tiếng nhất là phương pháp Phân tích Điểm

17


Chức năng (FPA - Function Point Analysis), mơ hình Giá Cấu thành COCOMO
(Constructive Cost Model) và phương pháp phân tích Use Case hệ thống (Use Case
Point BMT Analysis). Ba phương pháp này cịn có thể được kết hợp cùng nhau để
đánh giá tài nguyên cần thiết trong dự án.
1.3.1. Phương pháp phân tích Điểm Chức năng nghiệp vụ (FPA – Function
Points Analysis)
1.3.1.1. Tóm lược
Phân tích Điểm Chức năng nghiệp vụ (FPA) là một phương pháp đo kích cỡ
của phần mềm mà thể hiện qua việc định lượng các chức năng nghiệp vụ của hệ
thống được phân phối cho người dùng. Phương pháp này được đưa ra bởi tác giả
Allan Albretch thuộc tổ chức IBM, năm 1979.
1.3.1.2. Nội dung của phương pháp
3 bước để tiến hành đánh giá kích cỡ của một hệ thống được xây dựng bằng
phương pháp phân tích Điểm Chức năng:

-

Xác định kích cỡ xử lý thơng tin thô của hệ thống

-

Đánh giá Yếu tố Độ phức tạp Kĩ thuật của hệ thống

-

Tính tốn cuối cùng

Tính tốn cụ thể:
Bước 1: Xác định kích cỡ xử lý thơng tin thơ của hệ thống
Kích cỡ xử lý thơng được tính bởi phép xác định các thành phần hệ thống
như được thấy bởi người dùng cuối, và phân loại chúng thành 5 loại:
-

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

-

Các đầu ra ngoại vi

-

Các truy vấn ngoại vi

-

Các file logic nội bộ

-

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

“trung bình” hay “phức tạp” phụ thuộc số lượng phần tử dữ liệu mỗi loại và các yếu

18


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 =

∑

ni, j * Wi, j

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

ni, j

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

Wi, j

: là trọng số của loại i có độ phức tạp j

Loại chức năng

Độ phức tạp
Đơn giản

Trung bình

Phức tạp

Đầ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=

Tổng

UFPs =
Bảng 1- 1. Tính UFPs – kích cỡ xử lý thơng tin thơ – trong FPA
Bước 2: Đánh giá yếu tố độ phức tạp kỹ thuật của hệ thống
Kích cỡ xử lý thơng tin thô (UFPs) sẽ được điều chỉnh bởi các yếu tố kĩ
thuật, cái mà ảnh hưởng lên quá trình phát triển và thi hành hệ thống.
Mã yếu tố

Đặc trưng yếu tố

Mức độ ảnh hưởng

F1

Truyền thông dữ liệu

…

F2

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

…

F3

Hiệu năng

…

19


Đặc trưng yếu tố

Mã yếu tố

Mức độ ảnh hưở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 1- 2. Mười bốn Yếu tố kĩ thuật trong FPA
không xuất hiện, không ảnh hưởng = 0
ảnh hưởng không đáng kể = 1
ảnh hưởng vừa phải = 2
ảnh hưởng trung bình = 3
ảnh hưởng đáng kể = 4
ảnh hưởng mạnh, khắp nơi = 5
Có 14 yếu tố chuẩn, được tác giả Albretch đề xuất như là 14 “Đặc trưng ứng
dụng tổng quát”, sẽ được tính toán để đưa vào một con số được gọi là Yếu tố Độ
phức tạp Kỹ thuật (TCF – Technical Complexity Factor). Cụ thể, mức độ của
phạm vi ảnh hưởng của mỗi yếu tố được xếp loại và cho điểm từ 0 (không ảnh
hưởng) đến 5 (ảnh hưởng mạnh mẽ khắp nơi), như Bảng 2-2. Yếu tố Độ phức tạp

Kĩ thuật được tính theo cơng thức:
14

TCF = C1 + C2

∑

Fi

i =1

trong đó:

20


TCF là Yếu tố Độ phức tạp Kĩ thuật
C1 = 0.65
C2 = 0.01
Fi là mức độ ảnh hưởng của yếu tố kĩ thuật thứ i, có giá trị từ 0 đến 5
Để ý rằng đại lượng DI =

14

∑

Fi là mức độ ảnh hưởng tổng cộng (total

i =1

Degree of Influence) của 14 yếu tố, do đó cơng thức trên có thể viết lại thành:
TCF = C1 + C2 * DI
Bước 3: Tính tốn cuối cùng
Kích cỡ xử lý thơng tin của một hệ thống theo số lượng Điểm Chức năng
(FPs) được tính theo cơng thức:
FPs = UFPs * TCF
Trong đó:
FPs

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

UFPs : số điểm chức năng chưa được điều chỉnh được tính từ bước 1
TCF : yếu tố độ phức tạp kĩ thuật được tính từ bước 2
1.3.1.3. Đánh giá phương pháp
a) Ưu điểm
FPA đếm số chức năng dựa vào cách nhìn từ bên ngồi vào hệ thống của
người dùng cuối. Do đó, phương pháp là độc lập về mặt công nghệ, áp dụng phương
pháp FPA không yêu cầu 1 cách cụ thể nào của việc mơ tả hệ thống hay phát triển
hệ thống, ví dụ như, một phương pháp phân tích cụ thể.
Phép đo có thể được xác định sớm trong vịng đời phát triển của dự án, chỉ
cần có đặc tả yêu cầu người dùng, cho phép thực hiện đánh giá công sức dự án sớm,
hỗ trợ quản trị dự án.
b) Nhược điểm
FPA khơng thể được tính tốn một cách tự động, trong quy trình tính tố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

21

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
chun gia cũng có thể đưa ra những đánh giá kinh nghiệm có độ chính xác cao.
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
ngồ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ố

22


lượng file logic là không hề hợp lý. Các hệ cơ sở dữ liệu quản lý các bảng dữ liệu,
và như vậy đối tượng có thể đếm là số lượng các thực thể hoặc số lượng các bảng
(loại thực thể) chứ không phải là số lượng các file logic trong thao tác của hệ quản
trị cơ sở dữ liệu.
Một hạn chế nữa của FPA là mặc dù bình thường FPA làm việc cho các ứng
dụng nghiệp vụ, nhưng có thể nó khơng có hiệu lực cho các loại ứng dụng khác,
như là khoa học hay công nghệ. Điều này phát sinh từ chính khả năng có giới hạn
của nó để giải quyết độ phức tạp nội hàm. Độ phức tạp nội hàm trong các ứng dụng
nghiệp vụ phát sinh chủ yếu từ các tiến trình xác minh và từ các tương tác với dữ
liệu được lưu trữ. Trong khi các ứng dụng khoa học và kĩ thuật phải giải quyết các
thuật tốn tính tốn nội hàm phức tạp, thì FPA không phải là một cách hợp lý để
giải quết những hệ thống như thế.
1.3.2. Mơ hình đánh giá giá cấu thành (COCOMO – Constructive Cost Model)
1.3.2.1. Tóm lược
Mơ hình COCOMO là mơ hình đánh giá giá cấu thành (nỗ lực và thời gian)
của phần mềm dựa trên đánh giá kích cỡ của chương trình được phân phối cho
người dùng. COCOMO được giới thiệu lần đầu tiên năm 1981 trong cuốn sách
Software Engineering Economics của tác giả Barry Boehm.
1.3.2.2. Nội dung mơ hình
Có ba mức độ của mơ hình: Cơ sở, Trung cấp và Nâng cao.
a. Mơ hình COCOMO cơ sở (basic COCOMO)
Mơ hình COCOMO cơ sở tính tốn giá (nỗ lực và thời gian) phát triển phần
mềm như là một hàm của kích cỡ chương trình. Kích cỡ của chương trình được biểu
diễn theo đơn vị nghìn dịng lệnh (KLOC – kilo line of code).
Trước tiên, COCOMO phân biệt 3 phương thức phát triển dự án:
-

organic: cho những dự án tương đối nhỏ và đơn giản được phát triển bởi
những đội nhỏ trong môi trường quen thuộc với những yêu cầu không quá

23


cứng nhắc và có thể là linh động, do đó việc phát triển có thể được hỗ trợ bởi
những dự án đã được thực hiện trước đó.
-

semi-detached: cho những dự án có mức độ trung bình (về kích cỡ và độ
phức tạp) được phát triển bởi đội phát triển có trình độ khác nhau với những
ràng buộc mạnh mẽ hơn so với phương thức organic, tuy nhiên vẫn có một
số linh động, tức là dự án vẫn có thể được hỗ trợ từ những dự án trước đó
nhưng với mức độ ít

-

embedded: cho những dự án với những ràng buộc chặt chẽ về phần cứng,
phần mềm và thi hành, … Dự án phải phát triển từ đầu và không thể nhận
được sự trợ giúp từ những số liệu của các dự án khác.

Từ đó các phương trình của mơ hình COCOMO cơ sở là:
E = ab * (KLOC)bb
T = cb * db
P=E/T
trong đó:
KLOC : là số nghìn dịng lệnh của dự án
E

: là nỗ lực phát triển dự án theo đơn vị người – tháng,

T

: là thời gian phát triển dự án theo tháng,

P

: là số người phát triển,

ab, bb, cb, db : là các hệ số theo kinh nghiệm được cho theo phương
thức phát triển của dự án như bảng sau:
Phương thức

a

b

c

d

Organic

2.4

1.05

2.5

0.38

Semi - detached

3.0

1.12

2.5

0.35

embedded

3.6

1.2

2.5

0.32

Bảng 1- 3. Phân loại chế độ phát triển sản phẩm trong COCOMO cơ sở
b. Mô hình COCOMO trung cấp (intermediate COCOMO)

24