Bài giảng Đảm bảo chất lượng phần mềm - Chương 3: Các độ đo chất lượng phần mềm

Đảm bảo chất lượng phần mềm
Software Quality Assurance
Các độ đo chất lượng phần mềm
PGS. TS. Trần Cao Đệ
Bộ môn Công nghệ phần mềm 
Khoa CNTT&TT – Đại học Cần Thơ
Năm 2013
Các định nghĩa (Definitions)
• Số đo (Measure) trong CNPM là một danh từ:
số đo cung cấp một phạm vi, số lượng, kích thước, khả năng của một 
thuộc tính của một sản phẩm hoặc qui trình
• Đo (Measurement): là một hành động xác định số đo
• Độ đo (Metric):
– “a quantitative measure of the degree to which a system, component, 
or process possesses a given attribute” -- IEEE Standard Glossary
– Một số đo định lượng mức độ mà 1 hệ thống, 1 thành phần, 1 qui 
trình có một thuộc tính nào đó
• Chỉ báo (Indicator): 
– a metric or combination of metrics that provides insight into the 
software process, project, or product itself.
– Một độ đo hoặc tổ hợp các độ đo cung cấp cái nhìn sâu vào bên trong 
qui trình, dự án hoặc sản phẩm. 
3Độ đo CLPM (Software Quality Metric)
• SQM: độ đo xác định một số đo định lượng về mức độ mà một 
phần tử có được một thuộc tính chất lượng đã cho. Một đo lường 
định lượng
• Một hàm mà đầu vào là dữ liệu về phần mềm và đầu ra là một giá 
trị số phản ánh mức độ mà phần mềm có được một thuộc tính 
chất lượng nào đó
• Mục tiêu
– Dễ dàng kiểm soát, quản lí, lập kế hoạch và thực hiện các điều 
chỉnh về quản lí, dựa trên:
• Điều rút ra từ hiện thực so với hiệu năng mong đợi 
• Điều rút ra từ hiện thực so với thời gian, ngân sách dự kiến
– Xác định tình trạng cho các cải tiến qui trình phát triển và bảo trì 
phần mềm (các hoạt động ngăn lỗi hoặc sửa lỗi)
• Ví dụ: tích lũy các độ đo nhằm vào hiệu năng của nhóm làm việc
Phân loại độ đo phần mềm 
Classifications of software metrics 
• Theo giai đoạn của phần mềm 
– Các độ đo liên quan tới qui trình phát triển
– Các độ đo liên quan tới qui trình vận hành và bảo trì
• Theo chủ đề được đo 
– Chất lượng 
– Thời gian
– Hiệu quả (trong loại bỏ lỗi hoặc dùng tài nguyên)
Đo lường phần mềm - Software measures
• Đo kích thước - Software size measures
– KLOC – một độ đo kích thước phần mềm cổ điển bằng số ngàn dòng 
lệnh.
– Number of function points (NFP) – độ đo về công sức đòi hòi để phát 
triển phần mềm dựa vào đặc tả phần mềm.
• Độ đo chất lượng tiến trình phần mềm - Software process quality 
metrics
– Độ đo mật độ lỗi - Error density metrics (software volume + errors 
counted)
– Độ đo nhạy cảm với lỗi - Error sensitivity metrics
• Độ đo về khung thời gian của tiến trình - Software process 
timetable metrics
• Độ đo hiệu quả của việc loại trừ lỗi - Error removal effectiveness 
metrics
• Độ đo hiệu quả của tiến trình - Software process productivity 
metrics
Đo mật độ lỗi - Defect density
•Defect density measure
– Một chỉ báo sức khỏe phần mềm - an important health warning
–Một độ đo thực tế : a de-facto measure of software quality
Examples of Error density metrics 
•NCE = The number of code errors 
detected by code inspections and 
testing.
•NDE = total number of development 
(design and code) errors) detected in 
the development process.
•WCE = weighted total code errors 
detected by code inspections and 
testing.
•WDE = total weighted development 
(design and code) errors detected in 
development process.
Xác định độ đo phần mềm
Defining software (quality) metrics 
Thách thức đối với các độ đo phần mềm 
Challenge of Quality Metrics
• Mỗi phép đo dựa trên 1 cách nhìn khác nhau về chất 
lượng và độ p0hức tạp của hệ thống.
• Mục tiêu là pháp triển nhiều độ đo để nắm bắt các thuộc 
tính khác nhau như là chì số` chất lượng. Tuy nhiên, PP 
luận khoa học cho việc làm này chưa được đưa ra.
Nguyên tắc đo lường - Measurement Principles
• Công thức hóa (Formulation) – Rút ra các độ đo phù 
hợp cho phần mềm đang được xem xét.
• Tập hợp dữ liệu (Collection) – tích lũy dữ liệu để dẫn tới 
độ đo đã hình thức hóa
• Phân tích (Analysis) – tính toán dựa trên độ đo và áp 
dụng các công cụ toán học.
• Diễn dịch (Interpretation) – đánh giá độ đo dựa vào 
công sức để có được chất lượng của hệ thống
• Phản hồi (Feedback) – các khuyến nghị rút ra từ diễn 
dịch các độ đo.
Các đặc điểm của một độ đo hiệu quả 
Attributes of Effective Software Metrics
• Đơn giản và tính được - Simple and computable
• Phù hợp thực gnhiệm và trực quan - Empirically and 
intuitively persuasive
• Nhất quán và khách quan - Consistent and objective
• Nhất quán trong đơn vị và chiều - Consistent in units 
and dimensions
• Độc lập NNLT - Programming language independent
• Cơ chế phản hồi hiệu quả - Effective mechanism for 
quality feedback
Function Points
• The Function Point (FP) metric can be used as a means for predicting the 
size of a system (derived from the analysis model).
– number of user inputs
– number of user outputs
– number of user inquiries
– number of files
– number of external interfaces
Weighting Factor
MEASUREMENT PARAMETER count simple average complex total
number of user inputs 3 x 3 4 6 = 9
number of user outputs 2 x 4 5 7 = 8
number of user inquiries 2 x 3 4 6 = 6
number of files 1 x 7 10 15 = 7
number of external interfaces 4 x 5 7 10 = 20
count - total 50
FP = count-total  (0.65 + 0.01   Fi)
Chức năngVào
Ra
CSDL
Truy vấn
Hệ thống 
khác
Số files
PP Điểm chức năng
Độ đo thiết kế ở mực tổng thể 
High-Level Design Metrics
• Structural Complexity
– S(i) = f2out(i)
– fout(i) = fan-out of module i
• Data Complexity
– D(i) = v(i)/[fout(i) +1]
– v(i) = # of input and output variables to and from module i
• System Complexity
– C(i) = S(i) + D(i)
Độ đo hình thái hệ thống - Morphology Metrics
• size = n + a
• n = number of modules
• a = number of arcs (lines of control)
• arc-to-node ratio, r = a/n
• depth = longest path from the root to a leaf
• width = maximum number of nodes at any level
a
b c d e
f g i j k l
h m n p q r
size depth width arc-to node ratio
Độ đo thiết kế ở mức chi tiết
Component-Level Design Metrics
• Đo tính hợp nhất - Cohesion Metrics
• Đo phụ thuộc - Coupling Metrics
– Phụ thuộc vào dòng dữ liệu và điều khiển - data and 
control flow coupling
– Phụ thuộc tổng quan - global coupling
– Phụ thuộc môi trường - environmental coupling
• Đo độ phức tạp - Complexity Metrics
– Số Cyclomatic - Cyclomatic complexity
– Số này > 10 thì chương trình sẽ phức tạp và khó test 
Đo thiết kế giao diện - Interface Design Metrics
• Các thực thể trình bày (Layout Entities) - graphic icons, 
text, menus, windows, .
• Bố trí các thực thể phù hợp - Layout Appropriateness
– Vị trí tương đối, vị trí tuyệt đối của các thực thể trình bày 
absolute and relative position of each layout entity
– Tần suất dùng - frequency used
– Giá để chuyển từ thực thể này sang thực thể khác - cost 
of transition from one entity to another
• LA = 100 x [(cost of LA-optimal layout) / 
(cost of proposed layout)]
• Thiết kế giao diện cuối cùng nên dựa trên phản hồi từ 
các giao diện làm bản mẫu
Metrics for Source Code
• Software Science Primitives
– n1 = the number of distinct operators
– n2 = the number of distinct operands
– N1 = the total number of operator occurrences
– N2 = the total number of operand occurrences
– Length: N = n1log2n1 + n2log2n2
– Volume: V = (N1+N2)log2(n1 + n2)
– V = Nlog2(n1 + n2)
Ví dụ
1. Procedure sort(var x:array; 
n:integer);
2. Var i,j,save:integer;
3. Begin
4. for i:=2 to n do
5. for j:=1 to i do
6. if x[i]<x[j] then 
begin
7. save:=x[i];
8. x[i]:=x[j];
9. x[j]:=save
10. end
11. End;
operator
Procedure 1
Sort() 1
Var 2
: 3
Array 1
; 6
Integer 2
, 2
Begin end 2
For do 2
If then 1
:= 5
< 1
[] 6
n1=14
N1=35
operand
X 7
N 2
I 6
J 5
Save 3
“2” 1
“1” 1
n2=7
N2=25
Đo độ phức tạp theo McCabe 
McCabe’s Complexity
• Độ đo McCabe dựa vào dòng điều khiển trong chương trình
• Một chương trình được vẽ như là 1 sơ đồ dòng điều khiển.
• Nút biểu diễn cho công việc, mỗi công việc là 1 hoặc nhiều lệnh 
(một khối tuần tự các lệnh)
• Các cạnh là các dòng điều khiển giữa các nút
• V(G) = E – N + 2
– E : số cạnh trên sơ đồ dòng điểu khiển
– N: số nút
• Nếu chương trình được biểu diễn thành một đồ thị liên thông thì 
V(G) = P + 1
– Với P là số nút điều kiện (điều khiển rẽ nhánh)
1. Procedure sort(var x:array; 
n:integer);
2. Var i,j,save:integer;
3. Begin
4. for i:=2 to n do
5. for j:=1 to i do
6. if x[i]<x[j] then 
begin
7. save:=x[i];
8. x[i]:=x[j];
9. x[j]:=save
10. end
11. End;
Độ phức tạp: C=13-11+2=4
Độ đo cho kiểm thử - Metrics for Testing
• Các độ đo cho phân tích thiết kế, cài đặt dẩn dắt thiết kế 
và thực hiện các test cases
• Độ đo cho việc hoàn thành test - Metrics for Testing 
Completeness
• Độ rộng của phạm vi test - Breadth of Testing: tổng số 
yêu cầu được test
• Độ sâu của test - Depth of Testing: phần trăm các 
đường đi độc lập được test so với tổng số các đường đi 
độc lập trong chươnbg trình
• Tóm lược lỗi (Fault profiles) được dùng để ưu tiên hóa 
và phân loại các lỗi chưa được test bao trùm.
Độ đo cho bảo trì 
Metrics for Maintenance
• Chỉ số mức độ chín chắn - Software Maturity Index (SMI)
– MT = tổng số module trong release - number of modules in the current 
release
– Fc = tổng số module bị thay đổi trong release - number of modules in 
the current release that have been changed
– Fa = tổng số module dược thêm vào - number of modules in the 
current release that have been added
– Fd = tổng số module bị xóa - number of modules from the preceding 
release that were deleted in the current release
SMI = [MT - (Fc + Fa + Fd)] / MT
Độ đo cho TK HĐT
Metrics for OO Design
• Kích thước - Size
• Độ phức tạp - Complexity
• Độ gắn kết - Coupling
• Hiệu quả - Sufficiency
• Đầy đủ - Completeness
• Nhất quán - Cohesion
• Tính nguyên sơ - Primitiveness
• Đơn giản - Similarity
• Tính không bền vững - Volatility
Độ đo cho thiết kế HĐT 
Metrics for OO Design
• Kích thước - Size: được xác định theo các khung nhìn :
– Số lượng - Population: số lượng tĩnh các thực thể HĐT 
như số lớp số phép toán 
– Khối lượng - Volume: như số lượng nhưng là số lượng 
động tại một thời điểm nào đó 
– Độ dài - Length: dãy liên kết giữa các phần tử thiết kế
– Chức năng - Functionality: chỉ báo gián tiếp về giá trị 
chuyển giao cho khách hàng
Độ đo cho thiết kế HĐT 
Metrics for OO Design
• Độ phức tạp - Complexity
– Được xem xét theo cấu trúc viewed in terms of structural 
characteristics by examining how classes are related to 
one another
• Coupling
– the physical connections between elements (e.g. the 
number of messages passed between objects)
• Sufficiency
– the degree to which a design component fully reflects all 
properties of the application object it is modeling
• Completeness
– like sufficiency, but the abstraction is considered from 
multiple points of view, rather than simply the current 
application
Metrics for OO Design
• Cohesion
– the degree to which the OO properties are part of the 
problem or design domain
• Primitiveness
– applied to both operations and classes, the degree to 
which an operation is atomic (similar to simplicity)
• Similarity
– the degree to which multiple classes are similar in terms of 
structure, function, behavior, or purpose
• Volatility
– a measure of the likelihood that a change in design will 
occur
Chidamber and Kemerer measures 
• Chidamber and Kemerer have proposed six class-based design 
metrics for OO systems:
– Weighted methods per class (WMC)
– Depth of the inheritance tree (DIT)
– Number of children (NOC)
– Coupling between object classes (CBO)
– Response for a class (RFC)
– Lack of cohesion in methods (LCOM)
• Depth of the Inheritance tree (DIT)
– the maximum length from the node to the root of the tree
– as DIT grows, it becomes difficult to predict behavior of a class 
because of the high degree of inheritance
– Positively, large DIT values imply that many methods may be reused
Chidamber and Kemerer measures (cont.)
• Number of children (NOC)
– count of the subclasses immediately subordinate to a 
class
– as NOC grows, reuse increases
– as NOC grows, abstraction can become diluted
– increase in NOC means the amount of testing will 
increase
• Coupling between object classes (CBO)
– the number of collaborations listed for a class
– as CBO increases, reusability of the class decreases
– high CBO values complicate modifications
– in general, CBO values for each class should be kept as 
low as possible
Chidamber and Kemerer measures (cont.)
• Response for a class (RFC)
– the number of methods that can potentially be executed in 
response to a message received by an object
– as RFC increases, testing effort increases because the 
test sequence grows
– as RFC increases, the overall complexity of the class 
increases
• Lack of cohesion in methods (LCOM)
– measure of the number of methods within a class that 
access the same instance variables
– if no methods access the same attributes, LCOM = 0
– as LCOM increases, coupling between methods (via 
attributes) increases, and thus class complexity increases
Summary 
• Software metrics provide a quantitative way to asses the quality of 
product attributes.
• A software metric needs to be simple, computable, persuasive, 
consistent, and objective.
• The function point and bang metrics provide quantitative means for 
evaluating the analysis model.
• Metrics for design consider high-level, component level, and 
interface design issues.
• Interface design metrics provide an indication of layout 
appropriateness for a GUI.
• Using the number of operators and operands present in the code 
provides a variety of metrics to assess program quality.
• Using the metrics as a comparison with known successful or 
unsuccessful projects is better than treating them as absolute 
quantities.