Bài giảng Nhập môn công nghệ phần mềm - Trương Minh Thái - Chương 3: Ước lượng chi phí phần mềm

ghị sau khi nghiên cứu 60 dự án 
của IBM

 Có 29 yếu tố ảnh h−ởng tới hiệu suất
19

 Công thức −ớc l−ợng công sức E
E = 5.25 x S 0.91 (ng−ời - tháng)
Với S là kích th−ớc đ−ợc −ớc l−ợng của hệ thống 
(theo đơn vị ngàn dòng lệnh)

 Công thức −ớc l−ợng thời gian thực hiện 
T= 2.5 x E0.35 (tháng)
Mụ hỡnh Walston và Felix

 Mỗi yếu tố sẽ nhận 1 trong 3 giá trị tùy thuộc 
vào sự tác động của nó tới hiệu suất

 1 (cao): làm tăng hiệu suất
0 (trung bình): không ảnh h−ởng tới hiệu suất
20



 -1 (thấp): làm giảm hiệu suất
Mụ hỡnh 
Walston 
và Felix
1. Customer interface complexity 16. Use of design and code 
inspections 
2. User participation in requirements 
definition 
17. Use of top-down development 
3. Customer-originated program 
design changes 
18. Use of a chief programmer team 
4. Customer experience with the 
application area 
19. Overall complexity of code 
5. Overall personnel experience 20. Complexity of application 
processing 
6. Percentage of development 
programmers who participated in the 
design of functional specifications 
21. Complexity of program flow 
7. Previous experience with the 
operational computer 
22. Overall constraints on program’s 
design 
8. Previous experience with the 
programming language 
23. Design constraints on the 
program’s main storage 
21
9. Previous experience with 
applications of similar size and 
complexity 
24. Design constraints on the 
program’s timing 
10. Ratio of average staff size to 
project duration (people per month) 
25. Code for real-time or interactive 
operation or for execution under 
severe time constraints 
11. Hardware under concurrent 
development 
26. Percentage of code for delivery 
12. Access to development computer 
open under special request 
27. Code classified as 
nonmathematical application and 
input/output formatting programs 
13. Access to development computer 
closed 
28. Number of classes of items in the 
database per 1000 lines of code 
14. Classified security environment 
for computer and at least 25% of 
programs and data 
29. Number of pages of delivered 
documentation per 1000 lines of code 
15. Use of structured programming 
Mụ hỡnh Bailey và Felix

 Mô hình đ−ợc đề nghị năm 1981 bởi Bailey và Felix

 Mô hình này sử dụng cơ sở dữ liệu của 18 dự án viết 
bằng ngôn ngữ Fortran tại trung tâm Goddard Space 
Flight của NASA
22

 Các nhóm yếu tố ảnh h−ởng tới công sức: ph−ơng 
pháp, độ phức tạp và kinh nghiệm

 Công thức −ớc l−ợng công sức ban đầu E
E = 5.5 + 0.73xS 1.16 (ng−ời - tháng)
Với S là kích th−ớc đ−ợc −ớc l−ợng của hệ thống
Mụ hỡnh Bailey và Felix

 Mỗi yếu tố ảnh h−ởng tới công sức nhận một trong 
các giá trị từ 0 đến 5 
Total methodology 
(METH) 
Cumulative complexity 
(CPLX) 
Cumulative experience 
(EXP) 
Tree charts Customer interface Programmer 
23
complexity qualifications 
Top-down design Application complexity Programmer machine 
experience 
Formal documentation Program flow complexity Programmer language 
experience 
Chief programmer 
teams 
Internal communication 
complexity 
Programmer application 
experience 
Formal training Database complexity Team experience 
Formal test plans External communication 
complexity 
Design formalisms Customer-initiated 
program design changes 
Code reading 
Unit development 
folders 
Mụ hỡnh COCOMO 81

 Mô hình COCOMO 81 đ−ợc đề nghị bởi Boehm

 Dạng cơ bản: ỏp dụng cho nhúm nhỏ, mụi trường quen 
thuộc

 Dạng trung bỡnh: ỏp dụng cho dự ỏn khỏ lớn, cú một ớt 
24
kinh nghiệm

 Dạng lớn: ỏp dụng cho dự ỏn lớn, mụi trường mới

 Bảng mức độ khú khi phỏt triển sản phẩm
Mụ hỡnh COCOMO 81

 Công sức E = ab x S^bb x EAF

 ab và bb: đ−ợc xác định dựa vào bảng mức độ 
khó khi phát triển phần mềm

 EAF (effort adjustment factor): hệ số hiệu 
25
chỉnh công sức. Nó đ−ợc tính bằng tích của các 
hệ số phát triển

 S là kích th−ớc đ−ợc −ớc l−ợng của hệ thống 
(theo đơn vị ngàn dòng lệnh)

 Thời gian T = cb x E^db
Mụ hỡnh COCOMO 81

 Các hệ số phát triển
26
Mụ hỡnh COCOMO 2

 Mô hình COCOMO 81 đ−ợc phát triển trên giả 
thiết rằng tiến trình phát triển phần mềm thác n−ớc 
đ−ợc sử dụng và tất cả các phần mềm đ−ợc phát 
triển từ đầu.
27

 Mô hình COCOMO 2 đ−ợc thiết kế để thích ứng 
với những cách tiếp cận khác nhau đối với sự phát 
triển phần mềm
Mụ hỡnh COCOMO 2

 COCOMO 2 kết hợp chặt chẽ các mô hình con nhằm đ−a ra 
các dự đoán phần mềm chi tiết 

 Các mô hình con trong COCOMO 2 là:

 Mô hình Application composition: đ−ợc sử dụng khi phần 
mềm đ−ợc tạo thành từ các thành phần hiện có
28

 Mô hình Early design: đ−ợc sử dụng khi các yêu cầu là 
sẵn có nh−ng thiết kế vẫn ch−a đ−ợc bắt đầu

 Mô hình Reuse: đ−ợc sử dụng để tính công sức tích hợp 
các thành phần có thể dùng lại đ−ợc

 Mô hình Post-architecture: đ−ợc sử dụng ngay khi kiến 
trúc hệ thống đã đ−ợc thiết kế và các thông tin chi tiết 
hơn về hệ thống là sẵn có
Mụ hỡnh COCOMO 2
29
Mụ hỡnh Application composition

 Hỗ trợ các dự án bản mẫu và các dự án có sự tái sử dụng 
nhiều

 Đ−ợc dựa trên số l−ợng điểm ứng dụng (đối t−ợng)

 Công thức −ớc l−ợng
30

 Công sức
E = ( NAP x (1 - %reuse/100 ) ) / PROD (ng−ời – tháng)

 NAP: số l−ợng điểm ứng dụng

 PROD: hiệu suất. Nó phụ thuộc vào kinh nghiệm và
khả năng của nhà phát triển cũng nh− tính tr−ởng
thành và khả năng của công cụ
Mụ hỡnh Application composition

 Bảng xác định hiệu suất
31
Mụ hỡnh Application composition

 Số l−ợng điểm ứng dụng phụ thuộc vào:

 Các màn hình riêng biệt đ−ợc hiển thị

 Các báo cáo đ−ợc sinh ra bởi hệ thống
32

 Các module ch−ơng trình (đ−ợc viết bằng các 
ngôn ngữ lập trình nh− Java, C++, v.v) phải 
đ−ợc phát triển để bổ sung cho mã lệnh lập 
trình cơ sở dữ liệu
Mụ hỡnh Application composition

 Tính số l−ợng điểm ứng dụng 

 Đếm số l−ợng màn hình, báo cáo và module

 Xác định độ phức tạp cho từng thành phần (1 màn 
hình hay 1 báo cáo hay 1 module) theo bảng sau
33
8 + medium difficult difficult 4 + medium difficult difficult
For Screens For Reports
Number and source of data tables Number and source of data tables
Number of
views
contained
Total < 4
(<2
server,
<3
client)
Total < 8
(2-3
server,
3-5
client)
Total 8+
(>3
server, >5
client)
Number of
sections
contained
Total < 4
(<2
server,
<3
client)
Total < 8
(2-3
server, 3-
5 client)
Total 8+
(>3
server,
>5
client)
<3 simple simple medium 0 or 1 simple simple medium
3 - 7 simple medium difficult 2 or 3 simple medium difficult
Mụ hỡnh Application composition

 Tính số điểm ứng dụng cho từng thành phần khi 
đã biết độ phức tạp theo bảng d−ới đây
Object type Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
34

 Tính tổng số điểm ứng dụng cho tất cả các thành 
phần
3GL component - - 10
Mụ hỡnh Early design

 Các −ớc l−ợng có thể đ−ợc tạo ra sau khi các yêu cầu đ−ợc 
chấp nhận

 Công thức −ớc l−ợng

 Công sức E = a x Sb x M với
35

 M: tích của 7 hệ số nhân

 a = 2.94

 S kích th−ớc đ−ợc −ớc l−ợng của hệ thống (theo đơn vị
ngàn dòng lệnh)

 b thay đổi trong khoảng 1.1 tới 1.24 tùy thuộc vào tính
mới của hệ thống, tính linh động trong phát triển, các
ph−ơng pháp quản lý rủi ro và tính tr−ởng thành của
tiến trình
Mụ hỡnh Early design

 Các hệ số nhân phản ánh khả năng của nhà phát 
triển, các yêu cầu phi chức năng, sự hiểu biết rõ về 
nền tảng phát triển, v.v. 

 RCPX - product reliability and complexity

 RUSE - the reuse required
36

 PDIF - platform difficulty

 PREX - personnel experience

 PERS - personnel capability

 SCED - required schedule

 FCIL - the team support facilities

 Giá trị của các hệ số này nằm trong khoảng từ 1 
(rất thấp) đến 6 (rất cao)
Mụ hỡnh reuse

 Đ−a vào mã lệnh hộp đen đ−ợc tái sử dụng mà 
không cần thay đổi và mã cần phải đ−ợc sửa lại để 
tích hợp nó vào mã lệnh mới

 Hai loại tái sử dụng:
37

 Tái sử dụng hộp đen: mã lệnh không đ−ợc sửa đổi. 
Công sức phát triển cho mã hộp đen đ−ợc tính là 0

 Tái sử dụng hộp trắng: mã lệnh đ−ợc chỉnh sửa để nó 
có thể hoạt động trong hệ thống mới một cách chính 
xác. Một số công sức phát triển đ−ợc cần đến.
Mụ hỡnh reuse

 Nhiều hệ thống còn bao gồm các mã lệnh đ−ợc sinh ra một 
cách tự động từ các bộ dịch ch−ơng trình (một dạng tái sử 
dụng) 

 Dự đoán công sức để tích hợp mã lệnh đ−ợc sinh ra tự động:
E= (ASLOC * AT/100)/ATPROD
38

 ASLOC: số dòng mã lệnh trong các thành phần mà chúng 
đ−ợc sửa lại cho phù hợp

 AT: tỷ lệ phần trăm của mã lệnh đ−ợc sinh tự động

 ATPROD: hiệu suất của các kỹ s− trong việc tích hợp mã 
lệnh này
Mụ hỡnh Reuse 

 Dự đoán công sức để tích hợp các mã lệnh mới và các 
thành phần tái sử dụng hộp trắng:

 Không dự đoán công sức trực tiếp mà qua số dòng mã 
nguồn mới
ESLOC = ASLOC * (1-AT/100) * AAM
39

 ESLOC: số dòng mã nguồn mới t−ơng đ−ơng

 ASLOC và AT nh− tr−ớc

 AAM: hệ số nhân hiệu chỉnh sự thích ứng từ các chi 
phí của việc thay đổi mã lệnh tái sử dụng, các chi phí 
để hiểu cách tích hợp mã lệnh và các chi phí để ra 
quyết định tái sử dụng
Mụ hỡnh Post-architecture

 Sử dụng cùng một công thức nh− mô hình early 
design nh−ng có tới 17 hệ số nhân

 Công sức E = a x Sb x M với

 M: tích của 17 hệ số nhân
40

 a = 2.94

 S kích th−ớc đ−ợc −ớc l−ợng của hệ thống (theo
đơn vị ngàn dòng lệnh)

 b = 1.01 + 0.01 x ∑Wi với Wi là hệ số có giá trị
biến đổi từ 5 (rất thấp) tới 0 (cực kỳ cao)
Mụ hỡnh 
Post-
architecture

 17 hệ số nhân 
M
41
Mụ hỡnh Post-architecture

 Kích th−ớc mã lệnh S trong mô hình này đ−ợc 
tính bằng cách cộng ba −ớc l−ợng d−ới đây:

 Sự −ớc l−ợng về số dòng mã nguồn mới đ−ợc phát triển

 Sự −ớc l−ợng về số dòng mã nguồn t−ơng đ−ơng đ−ợc 
42
tính bằng cách sử dụng mô hình reuse

 Sự −ớc l−ợng về số dòng mã lệnh phải đ−ợc sửa đổi 
theo các thay đổi về yêu cầu
Mụ hỡnh Post-architecture

 Các hệ 
số W
43
Mụ hỡnh Post-architecture

 Các hệ số W
44