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 - Trần Cao Đệ

Đả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.