Bài giảng Bảo trì phần mềm - Phần III: Các vấn đề then chốt trong bảo trì phần mềm

 bảo trì viên 
 Tốc độ thay thế nhân sự bảo trì cao
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
15
Các vấn đề về quy trình
 Quy trình phần mềm là một tập hợp các hoạt động, 
phương pháp, thực tiễn và các biến đổi mà con người 
sử dụng để phát triển và bảo trì phần mềm và các sản 
phẩm liên quan.
 Các hoạt động của bảo trì phần mềm có nhiều điểm 
chung với phát triển phần mềm tại mức quy trình.
 Bảo trì phần mềm cũng có những hoạt động riêng, 
không có trong phát triển phần mềm.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
16
Các vấn đề về quy trình
 Một số hoạt động của bảo trì không có trong phát 
triển phần mềm: 
 Chuyển giao phần mềm từ tổ chức phát triển sang 
tổ chức bảo trì
 Viết cam kết, hợp đồng bảo trì
 Chấp nhận hay từ chối các yêu cầu thay đổi
 Phân tích sự tác động
Chúng là những thách thức đối với quản lý.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
517
Chọn nhóm bảo trì
 Trách nhiệm bảo trì phần mềm sẽ được giao cho:
 Nhóm phát triển ra chính sản phẩm hoặc
 Một nhóm riêng biệt không phải là nhóm phát triển. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
18
Chọn nhóm bảo trì
 Những thuận lợi khi giao nhiệm vụ bảo trì cho nhóm 
phát triển 
 Họ có kiến thức tốt nhất về hệ thống.
 Họ không cần đến các tài liệu được soạn thảo tỉ mỉ.
 Họ không cần thiết lập hệ thống giao tiếp chính thức 
giữa nhóm phát triển và nhóm bảo trì.
 Sự đáp ứng về mặt nhân sự tốt hơn do có sự đa dạng về 
khối lượng công việc.
 Người sử dụng chỉ cần làm việc với một tổ chức phần 
mềm.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
19
Chọn nhóm bảo trì
 Những khó khăn khi giao nhiệm vụ bảo trì cho nhóm 
phát triển 
 Nhà phát triển có thể rời khỏi tổ chức khi hoạt động bảo trì 
được thực hiện.
 Nhân sự mới có thể không hài lòng với khối lượng công 
việc bảo trì.
 Người có trách nhiệm bảo trì không được huấn luyện đầy 
đủ nếu chuyên gia phát triển rời khỏi tổ chức.
 Nhà phát triển thường tốn quá nhiều thời gian cho việc hoàn 
thiện hệ thống đã phát triển.
 Thường nhóm phát triển ban đầu được giao các dựa án mới.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
20
Chọn nhóm bảo trì
 Những thuận lợi khi giao nhiệm vụ bảo trì cho 
nhóm bảo trì
 Các tài liệu được tạo ra tốt hơn. 
 Bảo trì viên biết được các điểm mạnh, yếu của hệ 
thống.
 Các thủ tục thay thế nhân sự được xây dựng.
 Các thủ tục thực hiện sự thay đổi được thiết lập.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
621
Chọn nhóm bảo trì
 Những khó khăn khi giao nhiệm vụ bảo trì cho nhóm 
bảo trì
 Việc chuyển giao hệ thống bị chậm.
 Cần những huấn luyện quan trọng.
 Cần thời gian để hiểu hệ thống.
 Cần thời gian để thiết lập tổ chức bảo trì và các phương 
tiện. 
 Có thể có các vấn đề về tài chính.
 Có thể chất lượng của sự hỗ trợ từ người dùng kém.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
22
Chọn nhóm bảo trì
 Nhóm phát triển phần mềm thường không cần 
thiết được giao nhiệm vụ bảo trì phần mềm. 
 Nhóm bảo trì thường được chọn để đảm bảo rằng 
hệ thống hoạt động chính xác và tiến hóa nhằm 
đáp ứng các yêu cầu về sự thay đổi của người 
dùng. 
 Sự quyết định nên được đưa ra trên cơ sở của 
từng trường hợp. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
23
Gia công bảo trì phần mềm
 Gia công bảo trì đang trở thành một ngành công nghiệp 
chính. 
 Những thách thức chính với người gia công: 
 Xác định phạm vi của các dịch vụ bảo trì được yêu cầu 
và các chi tiết hợp đồng.
 Mất một khoảng thời gian để đánh giá phần mềm trước 
khi tiến hành ký kết hợp đồng.
 Gặp thách thức trong việc tiếp nhận sự chuyển giao 
phần mềm.
 Cần một khoản đầu tư ban đầu cho cơ sở hạ tầng, thiết 
lập quy trình, 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
24
Phép đo bảo trì phần mềm
 Các thực thể có thể đo
 Mục đích của việc đo
 Một số phép đo
 Kích thước
 Độ phức tạp
 Chất lượng
 Tính dễ hiểu
 Tính có thể bảo trì
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
725
Các thực thể có thể đo
 Phép đo BTPM tập trung nhiều hơn vào sự giải 
quyết vấn đề và sự quản lý các yêu cầu thay đổi
 Ba thực thể liên quan đến BTPM mà các thuộc 
tính của chúng có thể đo là:
 Quy trình: bất cứ hoạt động nào liên quan đến phần 
mềm
 Tài nguyên: đầu vào của quy trình 
 Sản phẩm: bất cứ kết xuất trung gian hay cuối cùng là 
kết quả của quy trình
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
26
Các thực thể có thể đo
Tài nguyên bảo trì Quy trình bảo trì Sản phẩm bảo trì
-Nhân công
-Công cụ
-Ngân sách
-Môi trường bảo trì
-Tiền phát hành và chuyển giao
-Hỗ trợ vận hành
-Hiệu chỉnh
-Cải tiến
-Giám sát sự thay đổi
-Kiểm thử hồi quy
-Quản lý cấu hình
-Tài liệu kỹ thuật
-Tài liệu người dùng
-Mã nguồn
-Mã đối tượng
-Báo cáo phân tích tác động
-Cơ sở dữ liệu 
tuân theo tạo ra
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
27
Quy trình bảo trì
Các yêu cầu bảo trì
Số lượng
Phân loại
Công sức
Người - Ngày
Input khác
Các công cụ
Các dịch vụ quản lý
Ứng dụng (Trước)
Kích thước chức năng
Dòng mã lệnh
Đặc điểm môi trường Ứng dụng (Sau)
Kích thước chức năng
Dòng mã lệnh
Đặc điểm môi trường
Các yêu cầu được hoàn thành
Số lượng
Phân loại
Kích thước chức năng
Dòng mã lệnh
Người - Ngày
 Đo quy trình bảo trì
 Xác định các hoạt động chính của quy trình
 Đo các đặc trưng của những hoạt động chính đó
Các 
thực 
thể 
có 
thể 
đo
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
28
Các thực thể có thể đo
 Đo tài nguyên
 Thực hiện ước lượng: công sức, số nhân công và ngân 
sách
 Hai phương pháp ước lượng phổ biến nhất trong 
BTPM là:
 Dựa vào kinh nghiệm
 Dùng các mô hình thông số
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
829
Các thực thể có thể đo
 Đo sản phẩm phần mềm
 Chất lượng của sản phẩm phần mềm là đặc biệt quan trọng 
đối với nhóm bảo trì.
 6 đặc trưng của chất lượng sản phẩm phần mềm được xác 
định bởi chuẩn ISO 2001
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
30
Mục tiêu của phép đo phần mềm
 Phép đo phần mềm được cần đến vì chúng được 
dùng để:
 Đánh giá các phương pháp, thư viện chương trình, 
công cụ để đưa ra quyết định cái nào là phù hợp nhất 
với một công việc cụ thể. 
 Kiểm soát quy trình của sự thay đổi phần mềm để đảm 
bảo các yêu cầu thay đổi được xử lý đúng và trong 
phạm vi ngân sách.
 Dự báo các khía cạnh khác nhau của chi phí, quy trình 
và sản phẩm phần mềm.
 Cải tiến các đặc trưng khác nhau của quy trình, hệ 
thống phần mềm (ví dụ: chất lượng, hiệu suất)
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
31
Đo kích thước (Size)
 Phép đo này thường được tính theo đơn vị ngàn dòng 
lệnh (KLOC, KDSI).
 Trong quá trình bảo trì, sự chú ý dồn vào dòng lệnh 
“delta”: số dòng lệnh được thêm vào hay được sửa 
đổi trong suốt quá trình bảo trì. 
 Các cách đo kích thước
 Đếm số dòng lệnh
 Tính số điểm chức năng
 Tính số điểm đặc trưng 
 Tính số trường hợp sử dụng
 Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
32
Đo kích thước
 Ưu điểm: Phép đo này dễ xác định và có tương 
quan mạnh với các phép đo khác như công sức 
hay mật độ lỗi. 
 Hạn chế: 
 Không có chuẩn nào cho phép đo LOC và phụ thuộc 
vào ngôn ngữ lập trình được sử dụng.
 Quá đơn giản và không phản ánh được chi phí hay 
năng suất. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
933
Đo độ phức tạp (Complexity)
 Không có một sự thống nhất nào về thuật ngữ “độ phức 
tạp”. 
 Trong bảo trì phần mềm, ta lưu ý xác định độ phức tạp 
của chương trình.
 Độ phức tạp của chương trình là sự khó khăn trong việc 
duy trì, thay đổi và hiểu chương trình. 
 Độ phức tạp của chương trình liên quan đến cấu trúc 
chương trình, nội dung ngữ nghĩa, dòng điều khiển, dòng 
dữ liệu và độ phức tạp của giải thuật. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
34
Đo độ phức tạp
 Chương trình càng phức tạp thì bảo trì viên càng có khả 
năng gây ra lỗi khi thực hiện một thay đổi. 
 Giá trị độ phức tạp càng cao, việc hiểu chương trình càng 
khó và vì thế khả năng có thể bảo trì càng thấp. 
 Độ phức tạp có thể được sử dụng để dự đoán công sức 
cần để tạo ra sự thay đổi cho chương trình.
 Hai phép đo phổ biến nhất đo độ phức tạp của mã lệnh: 
 Phép đo của McCabe 
 Phép đo của Halstead
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
35
Đo độ phức tạp
 Phép đo độ phức tạp của McCabe
 Một chương trình được xem như một đồ thị có hướng với 
nút là dòng lệnh và cung là dòng điều khiển giữa các lệnh. 
 Độ phức tạp của McCabe được tính theo công thức v(F) = e 
– n + 2 với:
 e: Tổng số cạnh hay cung
 n: Tổng số nút
 Giá trị này có thể giúp bảo trì viên:
 Cân nhắc xem chương trình có cần được hiệu chỉnh để làm 
giảm độ phức tạp hay không.
 Ước lượng thời gian cần để hiểu và hiệu chỉnh chương 
trình.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
36
Đo độ phức tạp
 Phép đo độ phức tạp của Halstead
Phép đo ảnh hưởng đến độ phức tạp: 
 Nỗ lực của chương trình 
E = (n1*N2*(N1+N2)*log(n1+n2)) / (2*n2)
Với:
 n1: Số các toán tử duy nhất được sử dụng 
 n2: Số các toán hạng duy nhất được sử dụng
 N1: Tổng số toán tử được sử dụng
 N2: Tổng số toán hạng được sử dụng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
10
37
Đo độ phức tạp
 Phép đo độ phức tạp của Halstead
 Phép đo của Halstead được sử dụng rộng rãi vì:
 Chúng dễ tính và không cần sự phân tích sâu các tính 
năng lập trình và dòng điều khiển
 Có thể được áp dụng cho bất cứ ngôn ngữ nào
 Tuy nhiên phép đo này chỉ dựa trên mã lệnh và mà 
không dựa vào các tài liệu để tính công sức hay sự hiểu 
biết chương trình. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
38
Đo chất lượng
 Chất lượng sản phẩm
 Số các yêu cầu thay đổi nhận được từ người dùng sau 
khi hệ thống được đưa vào vận hành. 
 Phép đo này chỉ bao gồm các yêu cầu mà chúng liên quan 
với các lỗi được phát hiện bởi khách hàng, không bao gồm 
các yêu cầu thay đổi nhằm cải tiến tính năng mà chúng 
không có trong đặc tả yêu cầu phần mềm. 
 Số lượng các yêu cầu thay đổi từ người dùng có thể được 
xem như chỉ số đo sự hài lòng của khách hàng. 
 Nó còn có thể được xem là chỉ số đo công sức (nỗ lực) bảo 
trì.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
39
Đo chất lượng
 Chất lượng sản phẩm
 Số lỗi được phát hiện sau khi hệ thống phần mềm đi 
vào hoạt động, thường là sau năm đầu tiên chuyển 
giao. 
 Các loại lỗi giống nhau được phát hiện bởi nhiều hơn 
một người được tính như một lỗi đơn. 
 Số lượng người sử dụng báo cùng một lỗi có thể được 
dùng như một phép đo về độ quan trọng của lỗi => một 
mức ưu tiên nên được gán cho lỗi. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
40
Đo chất lượng
 Chất lượng quy trình
 Kế hoạch
Thời gian thực hiện công việc theo kế hoạch - Thời gian thực hiện công việc 
trong thực tế để đạt được sự phát hành cho khách hàng đầu tiên
Thời gian thực hiện công việc theo kế hoạch
 Phép đo này được biểu diễn ở dạng tỷ lệ phần trăm
 Số âm có nghĩa là có sự sơ suất trong quá trình bảo trì
 Số dương có nghĩa là phát hành sớm 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
11
41
Đo chất lượng
 Chất lượng quy trình
 Năng suất
Số dòng mã lệnh được thêm vào hay được sửa đổi 
Công sức tạo ra sự bổ sung hay sự sửa đổi 
 Công sức là tổng thời gian từ lúc phân tích các yêu cầu 
thay đổi cho đến khi thực hiện thành công sự thay đổi. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
42
Đo tính dễ hiểu
 Tính dễ hiểu của chương trình không chỉ phụ 
thuộc vào mã nguồn mà còn phụ thuộc vào các 
yếu tố khác như tài liệu sẵn có, quy trình bảo trì 
và nhân sự bảo trì.
 Tính dễ hiểu thường tỷ lệ nghịch với độ phức tạp.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
43
Đo tính có thể bảo trì
 Tính có thể bảo trì không chỉ bị giới trong mã 
nguồn mà còn liên quan tới sự đặc tả, sự thiết kế 
và các tài liệu về kế hoạch kiểm thử. 
 Một số phép đo cho từng đặc điểm con của tính 
có thể bảo trì. 
 Đo tính có thể phân tích 
 Đo tính ổn định
 Đo tính dễ thay đổi
 Đo tính có thể kiểm thử
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
44
Đo tính có thể bảo trì
 Đo tính có thể phân tích
 Các phép đo công sức của bảo trì viên hay các tài nguyên 
được phát triển nhằm cố gắng dự đoán các thiếu sót hay các 
nguyên nhân lỗi, hay xác định các phần được hiệu chỉnh.
 Đo tính dễ thay đổi
 Các phép đo công sức của bảo trì viên có liên quan tới việc 
thực hiện một hiệu chỉnh xác định.
 Đo tính ổn định
 Các phép đo hành vi không mong đợi của phần mềm, bao 
gồm những vấn đề được bắt gặp trong suốt sự kiểm thử.
 Đo tính có thể kiểm thử
 Các phép đo công sức của bảo trì viên và người sử dụng 
trong việc cố gắng kiểm thử phần mềm được hiệu chỉnh. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
12
45
Đo chi phí
 Sẽ được trình bày chi tiết ở phần ước lượng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
46
Ước lượng chi phí bảo trì
 Các mối quan hệ cần lưu ý
 Các yếu tố kỹ thuật ảnh hưởng đến việc 
ước lượng
 Các yếu tố phi kỹ thuật ảnh hưởng đến việc 
ước lượng
 Ước lượng chi phí bằng mô hình điểm chức năng
 Ước lượng chi phí bằng mô hình COCOMO II
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
47
Các mối quan hệ cần lưu ý
 Mối quan hệ giữa khối lượng công việc BTPM và 
thời gian ứng dụng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
48
Các mối quan hệ cần lưu ý
 Mối quan hệ chi phí bảo trì phần mềm và các thành phần 
trong khung làm việc của bảo trì phần mềm
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
13
49
Các yếu tố kỹ thuật ảnh hưởng 
đến chi phí
 Ngôn ngữ lập trình 
 Phong cách lập trình
 Chất lượng tài liệu
 Sự độc lập của các thành phần
 Độ phức tạp của chương trình
 Kiểm thử
 Các kỹ thuật quản lý cấu hình
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
50
Các yếu tố phi kỹ thuật 
ảnh hưởng đến chi phí
 Lĩnh vực ứng dụng 
 Sự ổn định về nhân sự
 Tuổi của phần mềm
 Sự phụ thuộc của phần mềm vào môi trường 
 Nhu cầu của người sử dụng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
51
Ước lượng chi phí bảo trì bằng mô 
hình điểm chức năng
 Các loại điểm chức năng
 Các thành phần cơ bản trong từng loại điểm chức 
năng
 Bảng giá trị để tính từng loại điểm chức năng
 Công thức tính điểm chức năng trong BTPM
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
52
Mô hình điểm chức năng
 Các loại điểm chức năng
• Các điểm chức năng dữ liệu (Data 
Function Points) được đặc trưng 
bởi hai yếu tố:
• ILF (Internal Logical File)
• EIF (External Interface File) 
• Các điểm chức năng xử lý
(Transaction Function Point) được 
đặc trưng bởi ba yếu tố:
• EI (External Inputs)
• EO (External Outputs)
• EQ (External Inquiries)Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
14
53
Mô hình điểm chức năng
 Các loại điểm chức năng
 ILF là một nhóm các dữ liệu có liên quan về mặt logic có 
thể nhận dạng bởi người sử dụng trong phạm vi ứng dụng
và được cập nhật thông qua EI. 
 EIF là một nhóm các dữ liệu có liên quan về mặt logic chỉ 
được sử dụng cho mục đích tham khảo. Dữ liệu nằm ở bên 
ngoài phạm vi ứng dụng và được cập nhật bởi EI của các 
ứng dụng khác. Nó được lưu trữ trong tập tin.
 EI là một tiến trình căn bản trong đó dữ liệu được truyền từ 
bên ngoài vào bên trong phạm vi của ứng dụng. Dữ liệu có 
thể là thông tin điều khiển hoặc thông tin nghiệp vụ (thông 
qua màn hình nhập liệu hoặc từ một ứng dụng khác).
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
54
Mô hình điểm chức năng
 Các loại điểm chức năng
 EO là một tiến trình căn bản trong đó dữ liệu phát sinh 
được truyền từ bên trong ra bên ngoài phạm vi ứng dụng. 
Nó có thể là các báo cáo hay các tập tin kết xuất được gửi 
cho ứng dụng khác và được tạo ra từ những thông tin có 
trong một hay nhiều ILF hoặc EIF. (Dữ liệu phát sinh 
thường là kết quả của các giải thuật hay sự tính toán.)
 EQ là một tiến trình căn bản có hai chiều nhập dữ liệu và 
xuất dữ liệu nhằm truy xuất dữ liệu từ một hay nhiều 
ILF/EIF. Dữ liệu nhập không cập nhật ILF/EIF và dữ liệu 
xuất không phải là dữ liệu phát sinh.
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
55
 Các thành phần cơ bản
 FTR (File Type Referenced) là một loại tập tin được tham 
khảo bởi một xử lý. FTR phải là một ILF hoặc EIF.
 RET (Record Element Type) là các nhóm dữ liệu con liên 
quan về mặt logic trong ILF/EIF có thể nhận dạng bởi 
người sử dụng. Hầu hết các RET dựa vào mối quan hệ cha 
– con.
 DET (Data Element Type) là một trường không lặp lại, có 
thể nhận dạng bởi người sử dụng. DET là thông tin động, 
không phải là thông tin tĩnh. Nó là các trường nhập dữ liệu, 
các thông báo lỗi, các trường được hiển thị, các giá trị tính 
toán, các nút. 
Mô hình điểm chức năng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
56
 Tính số điểm chức năng thô (chưa được cân đối)
UFP = a1 x EI + a2 x EO + a3 x EQ + a4 x ILF + a5 x EIF
với a1, a2, a3, a4, a5 là giá trị các điểm chức năng theo độ 
phức tạp cho trong bảng sau.
Mô hình điểm chức năng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
15
57
 Tính số điểm chức năng được cân đối
Số điểm chức năng được cân đối cho các hoạt động thêm mới
Số điểm chức năng thô (thêm mới) x (0.65 + 0.01 x 
Tổng các mức độ ảnh hưởng của các hệ số kỹ thuật )
Số điểm chức năng được cân đối cho các hoạt động sửa đổi
Số điểm chức năng thô (hiệu chỉnh) x (0.65 + 0.01 x 
Tổng các mức độ ảnh hưởng của các hệ số kỹ thuật )
 Ước lượng số dòng lệnh LOC 
LOC = AVC * số điểm chức năng được cân đối 
(thêm mới + sửa đổi) 
với AVC: yếu tố phụ thuộc vào ngôn ngữ lập trình được sử dụng
Mô hình điểm chức năng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
58
8. Cập nhật trực tuyến
9. Xử lý phức tạp
10. Tính có thể tái sử dụng
11. Dễ cài đặt
12. Dễ vận hành
13. Đa nơi
14. Thay đổi thuận tiện
14 hệ số kỹ thuật
1. Giao tiếp dữ liệu
2. Chức năng phân tán
3. Sự thực thi
4. Cấu hình phụ thuộc
5. Tỷ lệ giao dịch
6. Nhập dữ liệu trực tuyến
7. Hiệu suất của người dùng cuối
14 hệ số kỹ thuật (có mức độ ảnh hưởng nằm trong phạm vi từ 0 
(không quan trọng hay không thích hợp hay không ảnh hưởng) tới 5 
(cực kỳ quan trọng hay cần thiết tuyệt đối hay ảnh hưởng nhất)
Mô hình điểm chức năng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
59
Bảng 
xác định 
giá trị 
AVC 
cho một 
số 
NNLT
Mô hình điểm chức năng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
60
 Đo kích thước bảo trì phần mềm
Trong đó:
 Base code size: Kích thước mã lệnh cơ sở
 MCF (Maintenance Change Factor): Hệ số thay đổi 
bảo trì. Nó được tính theo công thức:
 Size Added: Kích thước mã lệnh được thêm vào 
 Size Modified: Kích thước mã lệnh được sửa đổi.
Mô hình COCOMO II
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
16
61
 MAF (Maintenance Adjustment Factor): Hệ số điều 
chỉnh bảo trì
Trong đó:
 SU (Software Understanding): Sự hiểu biết phần mềm
 UNFM (Programmer Unfamiliarity): Sự không biết rõ 
của lập trình viên
Mô hình COCOMO II
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
62
 SU (Software Understanding): Sự hiểu biết về phần mềm
(theo tỷ lệ %)
Mô hình COCOMO II
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
63
 UNFM (Programmer Unfamiliarity): Mức độ không 
biết rõ của lập trình viên. 
Mô hình COCOMO II
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
64
Mô hình COCOMO II
 Công sức bảo trì phần mềm
 A: Hệ số công sức (có giá trị 2.94) 
 E: Hệ số mũ. Nó được xác định theo công thức 
 B: Hằng số có giá trị 0.91
 SF: Hệ số tỷ lệ
 EM (Effort Multiplier): Bội số công sức
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
17
65
 Bảng các hệ số tỷ lệ SF
Mô hình COCOMO II
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
66
Mô hình COCOMO II
 Bảng bội số công sức EM
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
67
Lưu ý
 Ước lượng chi phí bảo trì bằng kinh nghiệm 
 Dưới dạng đánh giá của chuyên gia dựa vào sự tương 
tự và cấu trúc phân chia công việc
 Là phương pháp được sử dụng để hoàn chỉnh kết xuất 
từ mô hình thông số nhằm đạt được một dự đoán. 
 Phương pháp tốt nhất cho dự đoán bảo trì phần 
mềm là kết hợp dữ liệu quá khứ và kinh nghiệm. 
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
68
ILF
EIF
EI
EO EQ
Tham 
khảo: 
Cách 
tính 
giá trị 
các 
loại 
điểm 
chức 
năng
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ
18
69
HẾT PHẦN III
Bộ môn CNPM, Khoa CNTT&TT, ĐH Cần Thơ