ĐÁNH GIÁ ĐỘ TIN CẬY PHẦN MỀM HƯỚNG ĐỐI TƯỢNG

LUẬN VĂN TỐT NGHIỆP
LUẬN VĂN TỐT NGHIỆP
ĐỀ TÀI:
ĐÁNH GIÁ ĐỘ TIN CẬY
ĐÁNH GIÁ ĐỘ TIN CẬY
PHẦN MỀM HƯỚNG ĐỐI TƯỢNG
PHẦN MỀM HƯỚNG ĐỐI TƯỢNG
MỤC LỤC
MỞ ĐẦU 8
1. Đặt vấn đề 8
2. Nhiệm vụ và bố cục của đồ án 9
CHƯƠNG 1: TỔNG QUAN VỀ LÝ THUYẾT 10
ĐO PHẦN MỀM 10
1.1 Lý thuyết đo 10
1.1.1 Cơ bản về lý thuyết đo 10
1.1.2 Lý thuyết đo – cách tiếp cận 12
1.2 Cơ sở lý thuyết về phép đo phần mềm 14
1.2.1. Vai trò của phép đo phần mềm 14
1.2.2. Mục đích và đối tượng của phép đo phần mềm 16
1.2.3 Các yêu cầu đối với một phép đo phần mềm 18
1.2.4 Các bước của quá trình đo phần mềm 18
1.2.5 Một ví dụ về phép đo phần mềm 18
1.2.6 Một số mô hình đo phần mềm 19
Ước tính chi phí và nhân lực 20
Mô hình đánh giá chất lượng 21
Mô hình đánh giá độ tin cậy 23
Mô hình đánh giá hiệu năng 25
Mô hình đánh giá độ phức tạp 25
1.3 Một số vấn đề về đo phần mềm 26
1.3.1 Phân biệt các đối tượng đo : sản phẩm, quá trình, nguồn lực 26
Phép đo quá trình 26

Phép đo sản phẩm 26
Phép đo nguồn lực 27
1.3.2 Phân biệt thuộc tính trong và thuộc tính ngoài 27
Kết luận chương 1: 28
CHƯƠNG 2: PHÉP ĐO PHẦN MỀM HƯỚNG ĐỐI TƯỢNG 29
2.1. Bộ các phép đo CK 30
2.1.1 Cơ sở lý thuyết của các phép đo CK 30
a. Cơ sở lý thuyết phát triển phần mềm hướng đối tượng 30
b. Cơ sở lý thuyết đo 31
c. Một số khái niệm 32
2.1.2 Các tính chất của phép đo hướng đối tượng 34
2.1.3 Các phép đo trong hệ đo CK 35
1. WMC (Weight Method per Class) 35
2. DIT (Depth of Inheritance Tree) 36
3. NOC (Number Of Children) 36
4. CBO (Coupling Between Object) 37
5. RFC (Responce For a Class) 37
6. LCOM (Lack of Cohesion in Methods) 37
2.1.4 Tổng kết về các phép đo CK: 38
2.1.5 Một ví dụ về các phép đo CK 39
2.2 Mô hình đánh giá chất lượng phần mềm hướng đối tượng 41
Mô hình REBOOT (ReusE Based on Object Oriented Technology) 41
Mô hình QMOOD (Quality Model for Object Oriented Design) 43
2
Kết luận chương 2: 46
CHƯƠNG 3: PHÂN TÍCH THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM TRỢ
GIÚP ĐO PHẦN MỀM 47
HƯỚNG ĐỐI TƯỢNG 47
3.1 Phân tích các yêu cầu 47
3.2 Các chức năng chính của chương trình 50

3.3 Cơ sở dữ liệu của chương trình 50
3.4 Chọn lựa công cụ thực hiện 51
3.5Xây dựng chương trình 52
a. Mô tả cơ sở dữ liệu 52
b. Giao diện của chương trình 53
c. Xây dựng các chức năng của chương trình 54
3.6Giới thiệu chương trình: 59
Mô tả chương trình nguồn: 59
Mô tả giao diện chương trình: 61
CHƯƠNG 4: MỘT SỐ KẾT QUẢ ĐO PHẦN MỀM 67
HƯỚNG ĐỐI TƯỢNG 67
4.1 Kết quả các phép đo CK 68
4.1.1. Kết quả độ đo LCOM 69
4.1.2 Kết quả độ đo DIT 70
4.1.3. Kết quả độ đo CBO 71
4.1.4 Kết quả độ đo NOC 72
4.1.5 Kết quả độ đo RFC 74
4.1.6 Kết quả độ đo WMC 75
4.1.7. Tổng hợp kết quả các độ đo CK 77
4.1.8 Quan hệ ảnh hưởng giữa các độ đo CK và các thuộc tính khác 78
4.2 Kết quả đo sử dụng mô hình QMOOD 80
4.2.1. Quá trình đo sử dụng mô hình QMOOD 80
4.2.2. Quan hệ ảnh hưởng giữa các kết quả đo và các thuộc tính khác 83
Nhận xét đánh giá về các kết quả đo thực nghiệm: 85
KẾT LUẬN 87
TÀI LIỆU THAM KHẢO 89
3
DANH MỤC CÁC HÌNH VẼ
Hình 1.1: Ví dụ về phép đo kích thước chương trình 11
Hình 1.2: Ví dụ kết quả phép đo phần mềm (Fsoft-fpt) 17

Hình 1.3: Mô hình FCM 21
Hình 1.4: Mô hình đánh giá phần mềm ISO 9126 22
Hình 1.5: Mô hình đánh giá khả năng bảo trì của IEEE 23
Hình 1.6: Đánh giá độ phức tạp qua lưu đồ chương trình 25
Hình 2.1: Ví dụ minh họa về các phép đo CK 40
Hình 2.2: Mô hình REBOOT 42
Hình 2.3: Mô hình QMOOD 45
Hình 3.1: Quy trình đo phần mềm hướng đối tượng 48
Hình 3.2: Sơ đồ hoạt động của chương trình 49
Hình 3.3: Các chức năng chính của chương trình 50
Hình 3.4: Các bảng trong cơ sở dữ liệu của chương trình 51
Hình 3.5: Chức năng nhập dữ liệu của chương trình 62
Hình 3.6: Chức năng tính toán và hiển thị độ đo trên mô hình 63
Hình 3.7: Chức năng tạo mới và sửa đổi mô hình 64
Hình 3.8: Chức năng mở CSDL 65
Hình 3.9: Chức năng phân tích kết quả đo 66
Hình 4.1: Kết quả độ đo LCOM 70
Hình 4.2: Kết quả độ đo DIT 71
Hình 4.3: Kết quả độ đo CBO 72
Hình 4.4: Kết quả độ đo NOC 73
Hình 4.5: Kết quả độ đo RFC 75
Hình 4.6: Kết quả độ đo WMC 76
Hình 4.7: Biểu đồ độ đo CK của các phần mềm 77
Hình 4.8: Dự đoán thuộc tính chất lượng dựa trên các độ đo CK 80
Hình 4.9: Kết quả đo một số thuộc tính của mô hình QMOOD 83
4
DANH MỤC CÁC BẢNG
Bảng 1.1: Phân công nhiệm vụ đo trong một tổ chức phần mềm 16
Bảng 1.2: Các hệ số trong mô hình COCOMO 20
Bảng 1.3: Các nhân tố chất lượng và tiêu chuẩn chất lượng trong ISO 9126 23

Bảng 2.1: Vai trò của các độ đo CK trong các giai đoạn thiết kế lớp 39
Bảng 2.2: Các dạng hàm chuẩn hóa độ đo 43
Bảng 2.3: Các tiêu chuẩn và độ đo trong mô hình QMOOD 44
Bảng 2.4: Mối liên hệ giữa các thuộc tính ngoài và thuộc tính trong 45
của mô hình QMOOD 45
Bảng 3.1: Một số công cụ đo phần mềm hướng đối tượng 48
Bảng 3.2: Công thức tính tham số cho các dạng hàm chuẩn hóa 57
Bảng 4.1: Danh sách các dự án được đo 68
Bảng 4.2: Tổng cộng số lớp các dự án được đo 68
Bảng 4.3: Kết quả độ đo CK của các phần mềm 77
Bảng 4.4: Hệ số tương quan giữa các độ đo CK và các chỉ số chất lượng 79
Bảng 4.5: Các hệ số của phương trình tuyến tính biểu diễn 80
phụ thuộc giữa thuộc tính chất lượng và độ đo 80
Bảng 4.6: Kết quả các độ đo của mô hình QMOOD 81
Bảng 4.7: Lựa chọn ngưỡng cho các hàm chuẩn hóa các độ đo 82
Bảng 4.8: Ngưỡng cho các hàm chuẩn hóa các độ đo QMOOD 82
Bảng 4.9: Kết quả đo một số thuộc tính của mô hình QMOOD 83
Bảng 4.10: Hệ số tương quan giữa các thuộc tính của mô hình QMOOD 83
với các thuộc tính chất lượng khác 83
Bảng 4.11: Hệ số tương quan giữa các độ đo và các chỉ số chất lượng 84
Bảng 4.12: Mối quan hệ ảnh hưởng giữa các độ đo và các chỉ số chất lượng 85
5
BẢNG GHI CHÚ CÁC THUẬT NGỮ
Viết tắt Viết đầy đủ Giải nghĩa
ADO Active Data Object Đối tượng để truy cập cơ sở dữ
liệu
ANA Average Number of Ancesters Trung bình số các lớp cha
API Application Programming
Interface
Giao diện lập trình ứng dụng

CAM
Cohesion Among Methods
in Class
Tính cố kết giữa các phương
thức trong cùng một lớp
CBO Coupling Between Object class Độ kết dính giữa các lớp
CIS
Class Interface Size
Kích thước giao diện lớp (số
phương thức public)
CK Chidamber, Kemerer Bộ các phép đo hướng đối
tượng do Chidamber, Kemerer
đề xuất [6]
COCOMO Constructive Cost Model Mô hình ước tính chi phí cho
các dự án phần mềm
CSDL
Cơ sở dữ liệu
DAM Data Access Metric Khả năng truy cập dữ liệu (tỷ lệ
số thuộc tính public)
DCC
Direct Class Coupling
Số lớp có tính kết dính với một
lớp
DIT Depth of Inheritance Tree Độ sâu cây thừa kế
DSC Design Size in Classes Số lớp của chương trình
FCM Factor-Criteria-Metrics Mô hình nhân tố-tiêu chuẩn-độ
đo để đánh giá chất lượng phần
mềm
GNU GNU Library General Public
License

Thư viện C++ của cộng đồng
mã nguồn mở
ISO 9126 International Standard
Organization
Mô hình đánh giá chất lượng
phần mềm của tổ chức tiêu
chuẩn quốc tế
JBOOMT Jade Bird Object Oriented
Metric Tool
Công cụ đo phần mềm hướng
đối tượng
JDK Java Developer Kit Thư viện lập trình Java của Sun
Microsystem
LCOM Lack of Cohesion among
Methods
Độ thiếu cố kết giữa các
phương thức (trong cùng 1 lớp)
LOC Lines of code Số dòng mã lệnh
MFA
Measure of Functional
Abstraction
Độ đo mức độ sử dụng thừa kế
của một lớp
6
MFC Microsoft Foundation Class Thư viện lập trình C++ của
Microsoft
MFM
Measure of Functional
Modularity
Độ đo về tính độc lập chức

năng
MOA
Measure of Aggregation
Sự tổ hợp giữa các lớp
MTBF Mean Time Between Failure Thời gian giữa các sai hỏng
MTTF Mean Time To Failure Thời gian đến sai hỏng
MTTR Mean Time To Repair Thời gian để sửa chữa
NOC Number Of Children Số con trực tiếp của một lớp
NOH Number Of Hierarchies Số các mức phân cấp
NOM
Number of Methods
Số phương thức trong lớp (độ
phức tạp của lớp)
NOP
Number of Polymorphic
Methods
Số phương thức đa hình
ODBC Open Database Connectivity Đối tượng để truy cập cơ sở dữ
liệu
OLEDB Object Linking Embedding –
Database
Đối tượng để truy cập cơ sở dữ
liệu
QMOOD Quality Model for Object
Oriented Design
Mô hình chất lượng cho phần
mềm hướng đối tượng
REBOOT ReusE Based on Object Oriented
Technology
Mô hình sử dụng lại cho phần

mềm hướng đối tượng
RFC Responce set For Class Tập trả lời của lớp (các phương
thức bị gọi bởi lớp đó)
STL Standard Template Library Thư viện lập trình C++ cung
cấp các tính năng mở rộng
WMC Weight Metric per Class Độ phức tạp của một lớp
7
MỞ ĐẦU
1. Đặt vấn đề
Đo phần mềm là một trong những nhiệm vụ đóng vai trò quan trọng trong các
hoạt động kỹ thuật phần mềm. Trong khi kỹ nghệ phần mềm đề cập đến các hoạt
động liên quan đến quá trình phát triển phần mềm, đo phần mềm liên quan đến
các đối tượng trong kỹ nghệ phần mềm mà có thể định lượng được. Một số ví dụ
điển hình là đo và dự đoán chi phí dự án, đo và dự đoán chất lượng của sản phẩm
phần mềm. Tất cả các ngành công nghệ đều xác định rõ vai trò quan trọng của
phép đo khi tiến hành bất kỳ một hoạt động sản xuất nào. Một dự án phần mềm
được tiến hành mà không gắn liền với quá trình đo có thể dẫn tới không thể kiểm
soát được thời gian hoàn thành sản phẩm, chất lượng sản phẩm bàn giao cho
khách hàng không được đảm bảo. Nếu không thể đánh giá một sản phẩm, chúng
ta cũng không thể đánh giá một phương pháp phát triển phần mềm mới là tốt hay
không tốt. Như vậy, có thể nói đo phần mềm đóng một vai trò quan trọng trong
kỹ nghệ phần mềm. Thực hiện đo phần mềm trong các dự án phần mềm nhằm
các mục đích: kiểm soát quá trình xây dựng phần mềm, đảm bảo hoàn thành sản
phẩm đúng thời hạn, kiểm soát chất lượng sản phẩm, dự đoán khắc phục các sự
cố có thể xảy ra, cải tiến quy trình sản xuất phần mềm.
Các hệ thống thông tin ngày nay ngày càng có độ lớn độ phức tạp, yêu cầu
phải được xây dựng trong một thời gian ngắn mà vẫn phải đảm bảo chất lượng.
Trước yêu cầu đó, kỹ nghệ phần mềm đã đưa ra những phương pháp phát triển
mới nhằm đáp ứng những đòi hỏi bức xúc đó. Phương pháp phát triển phần mềm
hướng đối tượng là một trong những cách tiếp cận cho phép rút ngắn thời gian

phát triển phần mềm qua việc sử dụng lại mã. Mỗi phương pháp phát triển mới
đều đòi hỏi có những phương tiện đánh giá phù hợp (đánh giá về quá trình, đánh
giá sản phẩm). Các phép đo phần mềm trước đây như đo số dòng mã lệnh không
thể hiện được tính chất hướng đối tượng của sản phẩm. Như vậy cần có những
phương pháp, công cụ phù hợp để đánh giá phần mềm hướng đối tượng.
Xuất phát từ các yêu cầu thực tiễn nêu trên, trong đồ án này, chúng tôi tập
trung nghiên cứu phép đo sản phẩm phần mềm được xây dựng trong môi trường
hướng đối tượng. Cơ sở lý thuyết của đề tài dựa trên lý thuyết đo phần mềm nói
chung và đo phần mềm hướng đối tượng nói riêng (các phép đo CK và mô hình
chất lượng ISO 9126). Phần phát triển của chúng tôi là đề xuất quy trình đo phần
mềm gồm 4 pha, xây dựng công cụ trợ giúp đo phần mềm hướng đối tượng, tiến
hành đo và phân tích kết quả đo một số phần mềm hướng đối tượng.
8
2. Nhiệm vụ và bố cục của đồ án
Đồ án này tập trung vào các vấn đề xoay quanh phép đo phần mềm hướng đối
tượng: lý thuyết đo phần mềm, tổng hợp các kết quả nghiên cứu về đo phần mềm
hướng đối tượng, đề xuất hướng nghiên cứu và phân tích các kết quả đo thực
nghiệm. Ba nhiệm vụ chính của đồ án như sau:
1. Tìm hiểu lý thuyết đo phần mềm, tổng hợp các kết quả nghiên cứu trên thế
giới về đo phần mềm. Chương 1 trình bày các vấn đề: cách tiếp cận lý thuyết
đo phần mềm dựa trên lý thuyết đo nói chung; các yêu cầu, vai trò, mục đích
đối với một phép đo phần mềm; một số kết quả nghiên cứu trên thế giới và
các phương pháp đo phần mềm được sử dụng rộng rãi trong công nghệ phần
mềm.
Tìm hiểu lý thuyết đo phần mềm hướng đối tượng, các kết quả nghiên cứu
về đo phần mềm hướng đối tượng. Chương 2 trình bày về các phép đo hướng
đối tượng, các mô hình đánh giá phần mềm hướng đối tượng.
2. Đề xuất và xây dựng công cụ trợ giúp cho quá trình đo phần mềm hướng đối
tượng (chương 3). Nhiệm vụ đặt ra là đề xuất một khung cho quá trình đo
phần mềm và xây dựng công cụ trợ giúp quy trình đó. Quy trình đo phần

mềm được đề xuất gồm có 4 bước: chọn lựa mô hình, thu thập dữ liệu, tính
toán trên mô hình và phân tích kết quả. Công cụ trợ giúp đo phần mềm hướng
đối tượng được xây dựng nhằm mục đích hỗ trợ quy trình đo phần mềm đú.
Cỏc mô hình và độ đo được lưu trữ trong cơ sở dữ liệu, người sử dụng có thể
sửa đổi mô hình hoặc xây dựng mô hình mới.
3. Tiến hành đo thực nghiệm và phân tích các kết quả đo được. Các kết quả đo
phần mềm được trình bày trong chương 4 là kết quả đo 8 dự án phần mềm ở
trung tâm xuất khẩu phần mềm Fsoft-fpt Hà Nội và 4 thư viện lập trình
hướng đối tượng gồm có MFC, JDK, GNU, STL. Công cụ xây dựng ở trên
được sử dụng để trợ giúp cho quá trình đo. Các kết quả đo được phân tích về
các khía cạnh: so sánh các giá trị đo giữa hai nhóm phần mềm, mối liên quan
ảnh hưởng giữa các độ đo và chất lượng phần mềm. Quá trình phân tích cho
thấy các kết quả đo phù hợp với lý thuyết về các phép đo hướng đối tượng
của Chidamber và Kemerer, rút ra những nhận xét về mối quan hệ ảnh hưởng
giữa các độ đo và chất lượng phần mềm. Các số liệu thống kê được chúng tôi
trình bày trên bảng và biểu đồ nhằm thể hiện tính trực quan tới người đọc.
Nội dung của đồ án được chia thành 4 chương như trên, phần cuối là kết luận,
đánh giá các kết quả đạt được và đề ra phương hướng phát triển tiếp theo của đề
tài trong tương lai.
9
CHƯƠNG 1: TỔNG QUAN VỀ LÝ THUYẾT
ĐO PHẦN MỀM
1.1 Lý thuyết đo
Trong cuộc sống hàng ngày chúng ta luôn luôn gặp các tình huống phải sử
dụng các phép đo. Tuy nhiên có thể do quá quen với các phép đo, chúng ta ít chú
ý đến bản chất của phép đo :
Đo là một quá trình mà kết quả là các ký hiệu được gán cho các thuộc tính
của thực thể theo một tập các luật được định nghĩa rõ ràng [10].
Như vậy phép đo liên quan đến thuộc tính của thực thể. Thực thể có thể là một
sự vật, một con người hay là pha kiểm tra của một dự án phần mềm .v.v. Thuộc

tính của thực thể có thể là chiều cao, chỉ số thông minh hay là độ phức tạp, độ tin
cậy .v.v. Chúng ta cần lưu ý là thực tế chúng ta không đo thực thể mà đo các
thuộc tính của thực thể. Phép đo gỏn cỏc ký hiệu cho các thuộc tính của thực thể
để mô tả chúng. Chẳng hạn khi đo chiều cao của người ta gán giá trị lớn hơn cho
người cao hơn, không phụ thuộc vào việc chúng ta sử dụng đơn vị đo là inches,
metres hay feet.
Trong vật lý, y học, kinh tế xã hội ngày nay chúng ta đã có thể đo được các
thuộc tính mà trước đây người ta chưa thể nghĩ là có thể đo được. Dựa trên kết
quả các phép đo về trí thông minh, chất lượng không khí, tỷ lệ lạm phát, . . .
người ta có thể đưa ra các quyết định quan trọng. Những phép đo như thế không
phải là cố định mà vẫn không ngừng được cải tiến.
Trong phần này chúng ta trình bày những vấn đề cơ bản của lý thuyết đo phần
mềm. Những vấn đề này sẽ là cơ sở cho các phần tiếp theo của đồ án.
1.1.1 Cơ bản về lý thuyết đo
Ở trên chúng ta đó nờu khái niệm về phép đo. Từ đó chúng ta đi đến khái
niệm sau: Đo là việc gán một giá trị số (hay ký hiệu) cho một thực thể để mô tả
một thuộc tính [10]. Như vậy phép đo bản thân nó là một ánh xạ từ tập thực thể
vào tập độ đo để mô tả thuộc tính.
10
Ví dụ:
Hình 1.1: Ví dụ về phép đo kích thước chương trình
Giả sử chúng ta muốn đo thuộc tính độ lớn của chương trình X. Phép đo có
thể được thực hiện bằng việc ánh xạ từ mã nguồn vào số câu lệnh của chương
trình. Kết quả của phép ánh xạ đó (100 trong ví dụ ở hình 1.1) để biểu diễn độ
lớn của chương trình. Tuy nhiên ngoài ra còn có thể có các phép đo khác ví dụ
như ánh xạ từ mã nguồn vào số bytes của chương trình (3000 trong ví dụ ở hình
1.1).
Để thực hiện phép đo chúng ta phải có một số hiểu biết về thuộc tính của thực
thể sắp tiến hành đo. Khi đã xác định được thực thể và có phương tiện (độ đo,
công cụ đo) thì mới có thể tiến hành đo. Phân tích kết quả đo giúp chúng ta có

hiểu biết về thuộc tính của thực thể, có thể có những cải tiến về độ chính xác,
đơn vị của phép đo.
Phép đo trực tiếp và phép đo gián tiếp
Chúng ta có thể đo các thuộc tính như là khối lượng và độ dài mà không cần
thông qua một thuộc tính nào khác. Trong khi đó việc đo thuộc tính mật độ yêu
cầu phải thông qua các thuộc tính khác (khối lượng và độ dài). Để phân biệt hai
phép đo này chúng ta có khái niệm:
Phép đo trực tiếp một thuộc tính là phép đo không phụ thuộc vào phép đo một
thuộc tính nào khác. Phép đo gián tiếp một thuục tớnh là phép đo liên quan đến
phép đo một số thuộc tính khác [10].
Một số thuộc tính, chẳng hạn nhiệt độ, chỉ có thể đo thông qua các thuộc tính
khác (trong trường hợp này là chiều cao của cột thủy ngân).
Việc phân loại phép đo trực tiếp và gián tiếp đề cập đến việc ánh xạ các qua
lại giữa các độ đo hơn là bản thân thuộc tính. Lý thuyết quan hệ về phép đo được
trình bày sau đây ban đầu chỉ liên quan đến các phép đo trực tiếp. Khi chúng ta
cần nghiên cứu cỏc thuục tớnh của thực thể mà trước đây chưa có phép đo nào để
đo các thuộc tính đó, chẳng hạn trong trường hợp các thuộc tính của phần mềm,
mà bản thân các thuộc tính như độ tin cậy, khả năng tái sử dụng, tính tiện dụng
giao diện người sử dụng cũng chưa được hiểu một cách xác đáng, thì cách tiếp
cận theo phương pháp đo gián tiếp là thích hợp.
11
X
100
3000
Số câu lệnh
Số byte
Chương trình
1.1.2 Lý thuyết đo – cách tiếp cận
Phần này chúng ta trình bày phương pháp biểu diễn phép đo. Phép đo được
mô hình hóa dựa trên các khái niệm : tập hợp, quan hệ và ánh xạ. Các thành phần

cơ bản của lý thuyết đo gồm có:
Hệ thống quan hệ: Xác định tính chất của các thuộc tính (tiên đề) qua các kết
quả quan sát trực giác hay là các hiểu biết ban đầu về thuộc tính. Các tính chất
này thường được thể hiện qua các quan hệ giữa các thực thể. Ví dụ như thuộc
tính độ nóng của dung dịch có mối quan hệ “núng hơn” giữa các dung dịch và
quan hệ này thỏa mãn tính bắc cầu.
Biểu diễn thay thế: Các thuộc tính có thể được biểu diễn bằng một hệ thống
trị số thích hợp bảo toàn các tính chất và quan hệ, việc biểu diễn này thực hiện
như là một ánh xạ từ tập thực thể vào tập trị số. Tiếp tục ví dụ độ nóng ở trên,
dung dịch A ánh xạ vào số x, dung dịch B ánh xạ vào số y, khi đó quan hệ “núng
hơn” được chuyển thành quan hệ “>”, ta phải có x>y.
Quan hệ chuyển đổi: Hai hàm bất kỳ từ thực thể sang trị số để biểu diễn
thuộc tính đều có một mối quan hệ nào đó. Chẳng hạn tất cả những gì chúng ta
biết về độ nóng của dung dịch là dung dịch này thỡ núng hơn dung dịch kia và
mối quan hệ nóng hơn này có tính bắc cầu. Hai hàm bất kỳ thể hiện độ nóng
được liên hệ bởi một sự chuyển đổi.
Một điểm lưu ý là mặc dù mong muốn của chúng ta là phép đo được thực hiện
khách quan nhưng các quan hệ ban đầu được thiết lập một cách chủ quan. Chẳng
hạn đo độ dài khi chưa có đơn vị đo thì đó là cách đánh giá chủ quan cái này dài
hơn cái kia. Khi nào các quan hệ chưa được xác lập một cách rõ ràng thì chỉ có
cách đánh giá chủ quan, ví dụ như việc đánh giá chất lượng rượu hay đánh giá độ
phức tạp của một chương trình. Cách làm có thể là đưa cho một nhúm cỏc
chuyên gia phân nhóm chương trình theo tính phức tạp từ 1 đến 5. Mặc dù việc
đánh giá đó chưa phải là phép đo theo đúng nghĩa của nó nhưng việc đánh giá
như thế là cần thiết, dần dần khi đó cú sự nhất trí về phân loại các thực thể dựa
trên tính chất, có thể dẫn đến một phép đo khách quan.
Hệ thống quan hệ
Giả sử tính chất của thuộc tính được biểu diễn bởi tập các quan hệ R, gọi tập
các thực thể là C, ta gọi hệ thống quan hệ là ξ = (C,R).
Ví dụ : Xét thuộc tính độ nghiêm trọng của sai hỏng phần mềm. Gọi C là tập

các sai hỏng phần mềm, ta xem xét 3 hệ thống quan hệ như sau:
12
1) Hệ thống quan hệ đơn giản trong đó chỉ có sự phân loại các sai hỏng phần
mềm chẳng hạn như: cú pháp, logic, đổ vỡ hệ thống. Giả thiết rằng các sai
hỏng phần mềm chỉ thuộc một trong ba loại trên.
Điều đó có nghĩa là chúng ta có một hệ thống quan hệ (C,R) trong đó R gồm
3 quan hệ đơn: quan hệ R
1
“là cỳ phỏp”, R
2
“là logic”, R
3
“là đổ vỡ hệ thống”.
Giả thiết rằng với mọi x∈C thì x là R
1
, R
2
, hoặc R
3
. Trong hệ thống quan hệ
này chúng ta chưa có đánh giá về trị số để so sánh tương đối về tính nghiêm
trọng giữa các sai hỏng, chúng ta chỉ biết rằng đó là các loại sai hỏng khác
nhau.
2) Chúng ta thêm vào quan hệ cũ một quan hệ mới R
4
“nghiờm trọng hơn”.
Thông thường ta quan niệm: các đổ vỡ hệ thống thì nghiêm trọng hơn sai
hỏng cú pháp và logic, các sai hỏng logic thì nghiêm trọng hơn sai hỏng về cú
pháp. R
4

gồm các cặp sai hỏng (x, y) trong đó hoặc: i)x∈R
3
và y∈R
2
hay R
1
,
ii) x∈R
2
và y∈R
1
. Hệ thống quan hệ mới cho tính nghiêm trọng các sai hỏng
phần mềm là (C, R’) trong đó R’ = {R
1
, R
2
, R
3
, R
4
}.
3) Nhằm đạt mục tiêu biểu hiện các hiểu biết sâu hơn về tính nghiêm trọng của
các sai hỏng phần mềm, chúng ta thêm vào hệ thống quan hệ R’ một quan hệ
mới: sự chênh lệch về độ nghiêm trọng giữa sai hỏng cú pháp và sai hỏng
logic cũng bằng với sự chênh lệch về độ nghiêm trọng giữa sai hỏng logic và
sai hỏng đổ vỡ hệ thống. Chúng ta có quan hệ R
5
với (x,y,x’,y’) ∈ R
5
nghĩa là

chênh lệch về độ nghiêm trọng giữa x và y bằng chênh lệch về độ nghiêm
trọng giữa x’ và y’ trong đó x là sai hỏng đổ vỡ hệ thống, y và x’ là sai hỏng
cú pháp còn y’ là sai hỏng logic. Chúng ta có hệ thống quan hệ mới (C, R’’)
trong đó R’’ = {R
1
, R
2
, R
3
, R
4
, R
5
}.
Hệ thống quan hệ dựa trên trị số (biểu diễn thay thế)
Sau khi tìm được hệ thống quan hệ cho thuộc tính, chúng ta cần tìm một ‘hệ
thống số, chẳng hạn như tập các số thực ℜ, để thực hiện ánh xạ các thực thể. Nói
đúng hơn chúng ta cần hệ thống quan hệ dựa trên trị số gồm có một tập hợp trị số
và các quan hệ trên tập đó. Mỗi quan hệ trong hệ thống cũ đều đòi hỏi một quan
hệ tương ứng trong hệ thống quan hệ dựa trên số. Đó gọi là điều kiện biểu diễn
thay thế cho hệ thống quan hệ. Ký hiệu N là tập trị số và P là tập quan hệ giữa
các trị số ta có hệ thống mới (N, P) .
Việc bảo toàn tất cả các quan hệ trong hệ thống số cho phép chúng ta định
nghĩa ánh xạ từ tập thực thể vào tập trị số N là một phép đo. Ta nói M là phép đo
một thuộc tính nếu đó là một ánh xạ từ hệ thống quan hệ (C, R) sang hệ thống
13
quan hệ dựa trên số (N, P). M thực hiện ánh xạ một thực thể thuộc C sang một trị
số thuộc N, và một quan hệ thuộc R sang một quan hệ thuộc P.
Ví dụ: Tiếp tục ví dụ về độ nghiêm trọng sai hỏng phần mềm ở trên. Chúng ta
tìm hệ thống quan hệ dựa trên trị số cho thuộc tính sai hỏng phần mềm.

1) Để tìm một biểu diễn thay thế cho R trong dạng số thực, ta lấy ba số phân biệt
bất kỳ, chẳng hạn 6, 2, 69. Chúng ta ánh xạ tất cả các sai hỏng cú pháp (các
thành phần của R
1
) vào số 6, các sai hỏng logic (thuộc R
2
) vào số 2, các sai
hỏng đổ vỡ hệ thống (thuộc R
3
) vào số 69. Để thỏa mãn điều kiện biểu diễn
thay thế, chúng ta chuyển các quan hệ R
1
, R
2
, R
3
thành các quan hệ P
1
, P
2
, P
3
đối với các số trong đó P
1
là quan hệ “là 6”, P
2
là quan hệ “là 2” và P
3
là quan
hệ “là 69”.

2) Để tìm một biểu diễn thay thế cho R’ chúng ta cần xem xét cẩn thận hơn khi
gỏn cỏc trị số. Trước hết chúng ta cần tìm quan hệ P
4
tương ứng với R
4
. Quan
hệ P
4
đương nhiên là >. Để hệ thống mới thỏa mãn quan hệ P
4
chúng ta cần
ánh xạ sai hỏng đổ vỡ hệ thống vào số lớn hơn sai hỏng logic và sai hỏng
logic vào số lớn hơn sai hỏng cú pháp. Như vậy có thể biểu diễn như sau: sai
hỏng cú pháp →1, sai hỏng logic→6, sai hỏng đổ vỡ hệ thống→ 7.
3) Để tìm biểu diễn thay thế cho R’’, chúng ta cần bảo toàn cả quan hệ R
5
, nghĩa
là sai khác giữa các trị số mà sai hỏng đổ vỡ hệ thống và sai hỏng logic ánh
xạ vào bằng sai khác giữa các trị số mà sai hỏng logic và sai hỏng cú pháp
ánh xạ vào. Một ánh xạ thỏa mãn là:
cú pháp →6, logic→8, đổ vỡ hệ thống→10.
1.2 Cơ sở lý thuyết về phép đo phần mềm
Phép đo phần mềm là phương tiện mà nhờ đó các kỹ sư phần mềm tính toán
và dự đoán được các khía cạnh khác nhau về các quá trình, tài nguyên, sản
phẩm liên quan tới hoạt động kỹ thuật phần mềm [7].
1.2.1. Vai trò của phép đo phần mềm.
“Chúng ta không thể kiểm soát cái mà chúng ta không thể đo được” [4]. Việc
phát triển phần mềm có chất lượng là rất cần thiết. Để đảm bảo chất lượng phần
mềm cần tiến hành các phép đo trong quá trình phát triển phần mềm. Chúng ta đã
biết rằng việc bảo dưỡng các hệ thống thông tin chiếm một tỷ lệ tài chính khá lớn

trong các dự án. Hệ thống có chất lượng kém cần phải bảo dưỡng nhiều hơn hệ
thống có chất lượng tốt. Một hệ thống được xây dựng mới mà không kèm theo sự
14
kiểm soát chất lượng chặt chẽ sẽ dẫn đến những yêu cầu bảo dưỡng tốn kém sau
này.
Mọi ngành công nghệ như điện, cơ khí, xây dựng không thể phát triển như
ngày nay nếu thiếu vai trò của đo đạc. Đối với ngành công nghệ phần mềm cũng
vậy, phép đo đóng một vai trò quan trọng. Những thiếu sót mà chúng ta thường
mắc phải khi phát triển phần mềm mà không sử dụng phép đo là:
1) Khi phát triển một sản phẩm phần mềm, chúng ta không đặt một mục tiêu rõ
ràng có thể đo được. Chúng ta nói rằng sản phẩm có tính “thõn thiện người sử
dụng”, “tin cậy cao”, “khả năng bảo trì tốt” nhưng không định nghĩa rõ những
thuộc tính này có ý nghĩa như thế nào xột trờn khía cạnh đo đạc. Như vậy
không thể khẳng định sự thành công của dự án nếu mục tiêu của nó là “mờ”.
2) Chúng ta không thể hiện chất lượng phần mềm dưới dạng lượng. Chúng ta
không thể nói với khách hàng rằng phần mềm mà chúng ta sản xuất sẽ chạy
trong bao lâu không bị sai hỏng với một độ tin cậy nào đó, hoặc là cần bao
nhiêu chi phí nhân lực để chuyển sản phẩm đó sang chạy ở một môi trường
khác.
3) Chúng ta hoàn toàn bị thuyết phục bởi việc sử dụng những phương pháp hay
công cụ mới được phát triển sẽ nâng cao chất lượng sản phẩm mà chúng ta
sản suất.
Thiếu sót của ngành công nghệ phần mềm là các phép đo được tiến hành
không thường xuyên, không phù hợp và không hoàn chỉnh. Phép đo phần mềm
phải được dựa trên những luận điểm cơ bản của lý thuyết đo. Chúng ta có thể
thấy những báo cáo khoa học công bố “80% chi phí sản xuất phần mềm là dành
cho pha bảo trỡ” hay “cứ 1000 dòng lệnh thỡ cú khoảng 55 lỗi”. Nhưng chúng ta
không biết những thí nghiệm đó được tiến hành như thế nào, vì thế ta không thể
lặp lại những nghiên cứu như thế trong môi trường của chúng ta để có kết quả so
sánh. Vậy vấn đề của phép đo phần mềm là thiếu một cách tiếp cận thống nhất

được áp dụng rộng rãi, dẫn đến các kết quả đo được thực hiện và công bố không
nhiều.
Thật không may là những nỗ lực nghiên cứu đánh giá về hiệu năng phần cứng,
đánh giá độ phức tạp tính toán cho ta những đánh giá rất tốt về những chương
trình nhỏ, những thuật toán nhưng không đánh giá được những hệ thống lớn
phức tạp là lĩnh vực của công nghệ phần mềm. Có thể nói nếu chúng ta không
xác định vai trò quan trọng của phép đo phần mềm thì cuộc khủng hoảng phần
mềm có thể ngày càng gay gắt hơn.
15
1.2.2. Mục đích và đối tượng của phép đo phần mềm
Sản xuất phần mềm đang gặp phải các vấn đề: chi phí sản xuất lớn (đặc biệt là
pha bảo trì), năng suất thấp và vấn đề đáng quan tâm là chất lượng kém. Nói tóm
lại sản xuất phần mềm không được kiểm soát chặt chẽ bởi vì chúng ta không tiến
hành đo đạc. Chúng ta có thể tóm tắt mục đích của phép đo phần mềm trong các
cụm từ: kiểm soát, đánh giá, dự đoán, cải tiến.
Đối tượng đo không chỉ có sản phẩm phần mềm mà gồm tất cả những thực thể
liên quan đến hoạt động sản xuất phần mềm như quy trình, nguồn lực. Ví dụ sau
sẽ giúp chúng ta có những ý tưởng ban đầu về các phép đo phần mềm:
Nhóm
người
Nhiệm vụ đo Mục đích
Nhà quản
lý
Chi phí cho các pha của dự án Kiểm soát chi phí nhằm
thu được lợi nhuận
Năng suất (năng lực sản suất) của nhân
viên
Trả tiền công cho nhân
viên
Chất lượng phần mềm được sản xuất So sánh các dự án, dự

đoán, thiết lập ranh giới
và mục tiêu cải tiến.
Đề xuất các phép đo sử dụng cho dự án. Nhân viên của dự án tiến
hành đo và báo cáo
Hiệu quả quy trình, nguồn lực Nhân tố nào ảnh hưởng
đến hiệu quả sản suất.
Hiệu quả của các phương pháp, công cụ Giới thiệu phương pháp
công cụ với cả công ty.
Kỹ sư
phần mềm
Quá trình: thay đổi ở pha thiết kế, lỗi ở
pha kiểm tra
Kiểm soát tiến triển của
hệ thống.
Cụ thể hóa các yêu cầu đo từ nhà quản
lý và tiến hành đo: lỗi / yêu cầu, kích
thước, chi phí,
Thông báo cho người
quản lý để có những
quyết định kịp thời.
Bảng 1.1: Phân công nhiệm vụ đo trong một tổ chức phần mềm
16
0%
20%
40%
60%
80%
100%
120%
Pay&Go

Proxigate 2.2.4
Gava
Report Writer
LS 2001
SmartTouch 2.0
Web Spider
NS Wap 2.5
CDB 1.2
PIM
HNWS
(a) Mức độ hoàn thành đúng thời gian (Timeliness)
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Pay&Go
Proxigate
Gava
Report
LS 2001
SmartTouch
Web Spider
NS Wap

CDB 1.2
PIM
HNWS
Average
PCost ACost Ccost
(b) Tỷ lệ chi phí cho việc đảm bảo chất lượng (Quality cost)
Hình 1.2: Ví dụ kết quả phép đo phần mềm (Fsoft-fpt)
Hình 1.2 là một ví dụ minh họa kết quả đo phần mềm được thể hiện trên đồ
thị. Hình 1.2a thể hiện độ đo mức độ hoàn thành đúng thời gian của các dự án
phần mềm, trục nằm ngang là các dự án, trục đứng thể hiện độ đo mức độ hoàn
thành đúng thời gian. Ý nghĩa của độ đo này như sau: giả sử một dự án phần
mềm phải thực hiện 5 lần bàn giao sản phẩm cho khách hàng, mỗi lần giao đúng
hạn thì được 20%, nếu dự án giao hàng chậm một lần thì dự án đạt 80%. Trong
hình 1.2a cú cỏc dự án Pay&Go và NS Wap 2.5 có kết quả độ đo này là 0%
nghĩa là giao hàng chậm trong tất cả các lần chuyển giao cho khách hàng.
Hình 1.2b thể hiện kết quả phép đo tỷ lệ các chi phí cho việc đảm bảo chất
lượng, gồm có chi phí cho việc đảm bảo quy trình (Process Cost – PCost), chi
phí cho việc kiểm định chất lượng sản phẩm (Assurance Cost – ACost), chi phí
cho việc chữa lỗi (Correction Cost).
17
1.2.3 Các yêu cầu đối với một phép đo phần mềm
o Đơn giản để có thể tính toán một cách dễ dàng.
o Có tính thực tế và tính thuyết phục cao (ví dụ giá trị đo được tỷ lệ với chất
lượng sản phẩm).
o Thể hiện tính khách quan (khi tiến hành bởi nhiều người khác nhau, bằng thủ
công hay bằng máy tính phải cho những kết quả tương tự nhau).
o Có đơn vị đo được chuẩn hóa (ví dụ giá trị đo được nằm trong khoảng 0 1,
càng gần 1 tức là chất lượng càng cao).
o Độc lập với ngôn ngữ lập trình.
o Có tính tích cực đối với quá trình nâng cao chất lượng sản phẩm (cung cấp

những thông tin phản hồi có giá trị cho nhóm phát triển phần mềm).
1.2.4 Các bước của quá trình đo phần mềm
Như phần 1.1.1 đã nói, khi muốn đo một thuộc tính của một thực thể nào đó,
chúng ta cần phải có một số hiểu biết về thuộc tính của thực thể sắp tiến hành đo,
sau đó cần có phương tiện để thực hiện phép đo (độ đo, công cụ đo). Khi cần tiến
hành đo phần mềm, chúng ta có thể tiến hành theo những bước sau [7]:
1. Lựa chọn phép đo. Tùy mục đích và môi trường phần mềm mà chúng ta lựa
chọn phép đo phù hợp.
2. Tiến hành đo trong môi trường phần mềm đó.
3. Đánh giá kết quả đo và có những cải tiến phép đo.
1.2.5 Một ví dụ về phép đo phần mềm
Trong phần này chúng ta đưa ra một ví dụ về phép đo của Halstead [5]. Phép
đo này dựa trên số toán tử và toán hạng có trong chương trình để đưa ra ước tính
về chi phí thời gian để viết đoạn chương trình đó.
Một chương trình P là tập hợp các ký hiệu, gồm có toán tử và toán hạng. Các
phép đo ban đầu được định nghĩa:
µ
1
= số toán tử phân biệt
µ
2
= số toán hạng phân biệt
N
1
= tổng số toán tử
N
2
= tổng số toán hạng
Độ dài của chương trình P được định nghĩa là N=N
1

+N
2
. Lượng từ vựng của P là
µ=µ
1
+µ
2
. Chi phí công sức (effort) để xây dựng chương trình P được ước tính
như sau:
18
2
21
2
log
µ
µµ
NN
E =
Thời gian thực sự cần để viết đoạn chương trình P được ước tính dựa trên kết quả
nghiên cứu của John Stroud [8]: T = E / 18 (giây). T = E / 18 (giây).
Ví dụ: Xét đoạn chương trớnh viết bằng FORTRAN sau:
SUBROUTINE SORT (A, N)
INTEGER A(100), N, I, J, SAVE, M
ROUTINE SORTS ARRAY A INTO DESCENDING ORDER
IF (N.LT.2) GO TO 40
DO 30 I=2, N
M=I-1
DO 20 J=1, M
IF (A(I).GT.A(J)) GO TO 10
GO TO 20

10SAVE = A(I) SAVE = A(I)
A(I) = A(J)
A(J) = SAVE
20CONTINUE CONTINUE
30CONTINUE CONTINUE
40RETURN RETURN
END
µ
1
= 14 µ
2
= 13
N
1
= 51N N
2
= 42
N = N
1
+ N
2
= 93
µ = µ
1
+ µ
2
= 27
2
21
2

log
µ
µµ
NN
E =
= 10045
T = E / 18 = 10045 / 18 = 558 giây ≈ 10 phút.
1.2.6 Một số mô hình đo phần mềm
Chúng ta đã biết tại sao trong công nghệ phần mềm cần tiến hành các phép đo.
Bây giờ chúng ta xem xét một số kết quả nghiên cứu đã đạt được trong phép đo
phần mềm. Các kết quả này bao gồm các vấn đề sau:
Mô hình đo và ước tính chi phí và nhân lực.
19
Mô hình đo năng suất.
Mô hình đánh giá chất lượng phần mềm.
Mô hình đánh giá độ tin cậy.
Mô hình đánh giá hiệu năng.
Độ phức tạp tính toán.
Độ phức tạp cấu trúc chương trình.
Ước tính chi phí và nhân lực
Yêu cầu này xuất phát từ phía nhà quản lý. Người quản lý muốn dự đoán sớm
chi phí cho các dự án sắp tiến hành. Một số mô hình đã được đề xuất là
COCOMO (Boehm) [1], Function Point (Albrecht) [6].
Dựa vào kết quả nghiên cứu các dự án phần mềm, người ta đưa ra các công
thức có thể ước tính trước chi phí cho các dự án sắp tiến hành. Mô hình
COCOMO (Constructive Cost Model) đưa ra công thức cơ bản của nó như sau :
i
b
i
KLOCaE )(=

i
d
i
EcD =
trong đo E là chi phí về nhân lực – tháng
D là thời gian cần để hoàn thành sản phẩm
KLOC là ước tính số nghìn mã lệnh
Các hệ số a
i
, b
i
, c
i
, d
i
được cho trong bảng 1.3, các dự án phần mềm được chia
thành ba loại: loại dự án nhỏ và đơn giản, loại dự án trung bình về mặt kích cỡ và
độ phức tạp, loại dự án lớn và phức tạp có sự ràng buộc giữa phần cứng và phần
mềm.
Dự án a
i
b
i
c
i
d
i
Nhỏ 2.4 1.05 2.5 0.38
Trung bình 3.0 1.12 2.5 0.35
Lớn 3.6 1.20 2.5 0.32

Bảng 1.2: Các hệ số trong mô hình COCOMO
Function Point tính dựa trên trọng số của các thông tin về : số đầu vào, số đầu
ra, số yêu cầu của người sử dụng, số file, số giao diện với bên ngoài.Trọng số
(weighting factor) này biểu hiện các thực thể trên là thuộc loại đơn giản, trung
bình hay phức tạp, lấy giá trị trong khoảng từ 3 đến 15. Ngoài ra người ta còn
phải trả lời 14 câu hỏi khác để thu được một giá trị gọi là trị số ảnh hưởng
(influence). Function point được tính như sau:
function point = SUM(weighting factor) * [0.65 + 0.01 * SUM(influence)]
20
Function point cũng là một thông số tốt để chỉ kích thước phần mềm. Phương
pháp này không phụ thuộc vào quy trình phát triển phần mềm và ngôn ngữ được
sử dụng. Tuy nhiên điểm yếu của phép đo này là sự đánh giá chủ quan khi trả lời
các câu hỏi và nó không thể tính tự động được.
Mô hình đánh giá chất lượng
Một số mô hình đánh giá chất lượng được sử dụng rộng rãi trong công nghệ
phần mềm gồm có: mô hình FCM, mô hình ISO 9126, Mô hình đánh giá nhân
tố - tiêu chuẩn (Factor-Criteria-Metrics, FCM) được xem là một thành phần cơ
bản để đánh giá chất lượng phần mềm. Nguyên tắc cơ bản của mô hình này là
mỗi thuộc tính được chia thành một tập các nhân tố mà bản thân chúng có thể
được chia thành một tập các tiêu chuẩn và các tiêu chuẩn được tính toán qua các
độ đo (metrics). Các mô hình chất lượng phần mềm của ISO và IEEE được xây
dựng dựa trên mô hình FCM.
Hình 1.3: Mô hình FCM
Các nhân tố, tiêu chuẩn và độ đo được sử dụng như sau : khách hàng và người
giám đốc chỉ quan tâm đến mức thuộc tính và mức nhân tố (factor, ví dụ như độ
tin cậy), người quản lý và điều hành dự án làm việc với mức tiêu chuẩn (criteria,
ví dụ như tính chính xác của kết quả thực thi chương trình), họ phải xem xét
những tiêu chuẩn nào ảnh hưởng đến nhân tố nào; ở mức sản xuất phần mềm,
nhân viên của dự án phải thu thập các độ đo (metric, ví dụ như số lỗi trong quá
trình kiểm tra).

Chất lượng phần mềm, theo ISO 9126, được hiểu là “tất cả các tính chất hay
thuộc tính của sản phẩm phần mềm làm cho nó có khả năng thích ứng với các
tình huống hay là thỏa mãn cỏc yờu cầu”. Ngoài ra, ISO 9126 cũng nêu ra chất
lượng phần mềm có 6 nhân tố sau:
21
Thuéc tÝnh
Nh©n tè 1
Tiªu chuÈn 1
§é ®o a
Nh©n tè 2
Nh©n tè n
Tiªu chuÈn 2
Tiªu chuÈn k
§é ®o b
§é ®o x
.
.
.
.
.
.
.
.
.
- Chức năng (Functionality) : là khả năng thực thi của phần mềm đáp ứng
những yêu cầu của người sử dụng.
- Độ tin cậy (Reliability) : sự đảm bảo được thực thi trong các tình huống khác
nhau
- Tiện dụng (Usability) : làm cho người sử dụng có thể hiểu, học và sử dụng
được phần mềm, có tính hấp dẫn đối với họ.

- Hiệu năng (Efficiency) : năng suất của hệ thống so với tài nguyên sử dụng
- Bảo trì (Maintainability) : Khả năng chữa lỗi, thay đổi, nâng cấp khi có yêu
cầu
- Tương thích (Portability) : khả năng chuyển đổi môi trường giữa các nền tảng
phần cứng hay phần mềm.
Hình 1.4: Mô hình đánh giá phần mềm ISO 9126
ISO 9126 là một mô hình chung để đánh giá chất lượng phần mềm, tùy từng
lĩnh vực cụ thể mà người sử dụng thiết lập các mô hình phù hợp. ISO 9126 cũng
đề xuất các nhân tố chất lượng có thể chia thành các tiêu chuẩn như sau:
Nhân tố chất lượng Tiêu chuẩn
Chức năng Tính phù hợp
Tính chính xác
Khả năng tương tác
22
ISO/IEC
9126
Tương thích
(Portability)
Độ tin cậy
(Reliability)
Tính tiện dụng
(Usability)
Chức năng
(Functionality)
Bảo trì
(Maintainability)
Hiệu năng
(Efficiency)
Tính tiện dụng
của phần mềm

Độ tin cậy của
phần mềm
Hiệu năng của phần
mềm
Khả năng thay đổi sửa
chữa phần mềm
Khả năng chuyển đổi phần
mềm sang chạy ở môi
trường khác
Chức năng yêu cầu có
được đáp ứng?
Đáp ứng đúng yêu cầu
Tính bảo mật
Độ tin cậy
Độ chắc chắn
Khả năng chịu lỗi
Khả năng phục hồi
Tính tiện dụng
Tính dễ hiểu
Khả năng học
Tính dễ sử dụng
Hiệu năng
Thời gian đáp ứng
Tài nguyên sử dụng
Khả năng bảo trì
Khả năng phân tích
Khả năng thay đổi
Tính ổn định
Khả năng kiểm tra
Tính tương thích

Khả năng thích ứng
Khả năng cài đặt
Tính phù hợp
Khả năng thay thế
Bảng 1.3: Các nhân tố chất lượng và tiêu chuẩn chất lượng trong ISO 9126.
Tuy nhiên các tiêu chuẩn trên được xác định thông qua các độ đo nào thì
không được ISO 9126 trình bày. Các độ đo này thỡ tùy từng lĩnh vực cụ thể mà
người sử dụng xác định tiêu chuẩn chất lượng nào được tính thông qua các độ đo
nào. Sau đây là một ví dụ về mô hình đánh giá khả năng bảo trì của IEEE:
Hình 1.5: Mô hình đánh giá khả năng bảo trì của IEEE
Mô hình đánh giá độ tin cậy
Độ tin cậy là một thuộc tính trong mô hình chất lượng ISO 9126. Quan điểm
về độ tin cậy phần mềm được chấp nhận rộng rãi đó là khả năng thực thi thành
công phần mềm đó, như vậy đối tượng cho phép đo độ tin cậy chỉ có thể là sản
phẩm ở dạng mó mỏy. Đây là một trong những thuộc tính quan trọng nhất của
chất lượng phần mềm. Độ tin cậy thường được đánh giá dựa trên số lỗi tìm thấy
trong pha kiểm tra, hoặc là dựa trên thời gian không bị sai hỏng trong pha kiểm
23
Bảo trì
Tính chính xác
Khả năng test
Khả năng mở
rộng
Lỗi
Mức độ kiểm tra
Chi phí
nhân lực
Thay đổi
Thời gian không bị lỗi
Thời gian sửa chữa

Tỷ lệ lỗi
Mứu độ bao phủ các câu lệnh
Mức độ hoàn thành kế
hoạch test
Nguồn nhân lực
Ảnh hưởng của các thay đổi
Tỷ lệ thay đổi
Nhân tố Tiêu chuẩn Độ đo
tra. Mô hình đánh giá độ tin cậy đơn giản nhất là độ tin cậy được tính bằng tỷ lệ
lỗi của phần mềm:
Tỷ lệ lỗi = số lỗi tìm thấy / kích cỡ chương trình
Một cách đánh giá độ tin cậy thường dùng trong các hệ thống tin học là dựa
trên thời gian giữa các sai sót, tính bằng tổng của thời gian đến sai sót (MTTF)
và thời gian để sửa chữa (MTTR).
MTBF = MTTF + MTTR
Theo cách này, độ tin cậy phần mềm được tính qua tính sẵn sàng của nó, bằng
tỷ lệ thời gian nó hoạt động không bị lỗi:
Tính sẵn sàng = MTTF / (MTTF + MTTR) * 100
Độ tin cậy là một thuộc tính rất quan trọng của chất lượng phần mềm, tuy
nhiên độ tin cậy thường được xác định muộn, sau khi đã có mã lệnh thực thi
chương trình. Vì vậy cần có các phương pháp đánh giá độ tin cậy sớm trong quá
trình phát triển phần mềm để có những cải tiến khắc phục kịp thời nhằm nâng
cao chất lượng sản phẩm, giảm chi phí chữa lỗi cho dự án.
Trong đề tài nghiên cứu về đánh giá phần mềm, chúng tôi đã đề xuất mô hình
đánh giá độ tin cậy phần mềm dựa trên độ tin cậy các thành phần của phần mềm
đó [16]. Công thức biểu diễn độ tin cậy hệ thống theo độ tin cậy các thành phần
như sau:
∑
=
−≈−=

m
k
kkss
DQR
1
11
ϕ
∑
=
=+++≈
m
k
kkmms
DDDDQ
1
2211

ϕϕϕϕ
Trong đó:
R
s
: độ tin cậy của hệ thống
Q
s
: độ không tin cậy của hệ thống (Q
s
= 1- R
s
)
D

i
: xác suất sai hỏng của thành phần i của hệ thống
ϕ
i
: tỷ lệ thời gian thực thi thành phần i trên tổng thời gian thực thi của hệ
thống.
m: số thành phần của hệ thống
Ưu điểm của mô hình trên là công thức đơn giản, cho phép ước lượng sớm về
độ tin cậy của hệ thống. Tuy nhiên, vấn đề còn tồn tại trong phương pháp này là
cỏch tớnh độ tin cậy qua các mẫu thử chưa chính xác, chưa xét đến độ tin cậy các
giao diện giữa các thành phần. Phương pháp này cần phải được nghiên cứu kỹ
lưỡng hơn mới có thể áp dụng vào thực tiễn.
24
Mô hình đánh giá hiệu năng
Hiệu năng cũng là một thuộc tính trong mô hình phân cấp chất lượng (chúng
ta gọi mô hình chất lượng phần mềm ISO 9126 là mô hình phân cấp chất lượng).
Cũng giống như thuộc tính độ tin cậy, hiệu năng có thể đánh giá qua sự thực thi
của sản phẩm phần mềm, qua tài nguyên và bộ nhớ mà nó yêu cầu. Tuy nhiên
ngay cả trong trường hợp không biết cụ thể về môi trường thực thi của phần
mềm, chương trình dịch được sử dụng, chúng ta vẫn có thể đánh giá hiệu quả
thực thi của chương trình qua độ phức tạp tính toán của thuật toán được sử dụng.
Mô hình đánh giá độ phức tạp
Hình 1.6: Đánh giá độ phức tạp qua lưu đồ chương trình
Một chương trình được xét dưới dạng một đồ thị với một điểm vào và một
điểm ra. Dùng lý thuyết đồ thị có thể xác định được số đường đi từ điểm đầu đến
điểm cuối. Độ phức tạp của chương trình được định nghĩa bởi cấu trúc điều khiển
của nó và đặc trưng bằng tổng số các con đường độc lập tuyến tính đi qua
chương trình. Biểu thức xác định độ phức tạp cyclomatic [13]:
v(G) = e – n + 2p
trong đó : e = số cạnh của đồ thị

n = số đỉnh của đồ thị
p = số thành phần kết nối của đồ thị
25