Bài giảng Đảm bảo chất lượng phần mềm: Chương 4 - PGS.TS. Trần Cao Đệ

Bài giảng Đảm bảo chất lượng phần mềm - Chương 4: Các độ đo chất lượng phần mềm cung cấp cho người học các kiến thức: Các định nghĩa, độ đo CLPM (Software Quality Metric), phân loại độ đo phần mềm - Classifications of software metrics,... Mời các bạn cùng tham khảo.

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

Độ đ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

– 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ì

– 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

Đ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ơ 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 external interfaces 4 x 5 7 10 = 20

FP = count-total  (0.65 + 0.01   Fi)

Số files

PP Điểm chức năng

– D(i) = v(i)/[fout(i) +1]

– v(i) = # of input and output variables to and from module i

– 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

Độ đ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)

Đ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

1 Procedure sort(var x:array;

Độ đ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 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

– like sufficiency, but the abstraction is considered from

multiple points of view, rather than simply the current

application

Metrics for OO Design

– 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)

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

– 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.