Thông số phần mềm cung cấp một thước đo cho phần mềm và quy trình sản xuất phần mềm. Là một khái niệm quan trọng trong kỹ thuật phần mềm, có nhiều định nghĩa về thông số phần mềm. Dưới đây là một trong những định nghĩa về thông số phần mềm làm nổi bật vai trò của mục tiêu đo lường và quá trình:
Đo lường phần mềm cung cấp các biện pháp liên tục cho quá trình phát triển phần mềm và các sản phẩm liên quan của nó. Nó xác định, thu thập và phân tích dữ
liệu của quá trình đo lường được, mà qua đó nó tạo điều kiện cho sự hiểu biết, đánh giá, kiểm soát và cải thiện quy trình sản phẩm phần mềm.
Số liệu phần mềm được phân loại theo ba nhóm chính, cụ thể là số liệu sản phẩm, số liệu quá trình và số liệu tài nguyên. Số liệu sản phẩm liên quan đến đo lường của tính năng khác nhau của tài liệu và các chương trình được tạo ra trong quá trình phát triển phần mềm. số liệu quá trình liên quan đến đo lường các hoạt động xảy ra trong suốt vòng đời phần mềm phát triển, chẳng hạn như thiết kế phần mềm, thực hiện, kiểm tra, bảo trì. Số liệu tài nguyên biện pháp hỗ trợ tài nguyên như các lập trình viên, và chi phí của sản phẩm và quy trình, vv...
Bằng cách xem xét các số liệu của mã nguồn, các nhà phát triển có thể hiểu được phần nào nên được làm lại hoặc kiểm tra kỹ lưỡng hơn. Nhóm phát triển có thể xác định những rủi ro tiềm năng, hiểu được trạng thái hiện tại của một dự án, và theo dõi tiến độ trình phát triển phần mềm. Một số các thông số thông dụng:
- Maintainability Index - Tính toán giá trị chỉ số giữa 0 và 100 đại diện cho độ dễ dàng bảo trì của mã nguồn. Giá trị cao có nghĩa là càng dễ bảo trì. Giá trị giữa 20 và 100 và chỉ ra rằng các mã nguồn có khả năng bảo trì tốt. Giá trị giữa 10 và 19 và chỉ ra rằng mã nguồn có khả năng bảo trì vừa phải. Giá trị từ 0 đến 9 và chỉ ra khả năng bảo trì thấp.
- Cyclomatic complexity - Đo cấu trúc phức tạp của mã nguồn. Nó được tạo ra bằng cách tính toán số lượng các đường dẫn mã nguồn khác nhau trong flow của chương trình. Một chương trình có kiểm soát flow phức tạp đòi hỏi phải có thêm các thực nghiệm để đảm bảo cover hết mã nguồn và ít cần bảo trì hơn.
- Depth of Inheritance - Cho biết số lượng các lớp được định nghĩa mà mở rộng đến thư mục gốc của hệ thống phân cấp lớp. Các hệ thống càng phân cấp thì càng khó có thể hiểu được nơi mà các hàm và các trường cụ thể được xác định
hoặc định nghĩa lại.
- Class Coupling - Đo mức độ gắn kết của các lớp thông qua các tham số, các biến địa phương, các loại giá trị trả về, các hàm được gọi, các khởi tạo, các lớp cơ sở, triển khai giao diện, các trường quy định về các loại bên ngoài, và thuộc tính trang trí. Một thiết kế phần mềm tốt là thiết kế sao cho các loại và hàm nên có sự tập trung cao vào mục đích của lớp và độ gắn kết giữa các lớp nên thấp. Độ gắn kết cao cho thấy thiết kế đó là rất khó để tái sử dụng và bảo trì bởi vì tồn tại nhiều phụ thuộc lẫn nhau của các lớp.
- Lines of code - là dòng trong mã nguồn. Thông số này được tính toán dựa trên mã IL và do đó không phải là con số chính xác của các dòng trong tập tin mã nguồn. Chỉ số này cao chỉ ra rằng một loại hoặc một hàm đang cố gắng làm quá nhiều công việc và cần được tách ra. Nó cũng có thể chỉ ra rằng các loại hoặc các hàm khó khăn trong việc bảo trì.
Đó là các số liệu cơ bản, ngoài ra trong các dự án thực tế người ta sử dụng rất nhiều thông số tùy theo tính chất, phương thức tiến hành dự án cũng như những yêu cầu cần theo dõi khi xây dựng phần mềm.
Một ví dụ minh họa cho các thông số được các công ti sử dụng để đo đạc, thu thập dữ liệu từ các dự án:
Nasa sử dụng 37 thông số, hay còn gọi là các đặc trưng để đánh giá các module của dự án, cụ thể đó là:
loc_blank, branch_count, call_pairs, loc_code_and_comment, loc_comments, condition_count, cyclomatic_complexity, cyclomatic_density, decision_count, decision_density, design_complexity, design_density, edge_count,
essential_complexity, essential_density, loc_executable, parameter_count, halstead_content, halstead_difficulty, halstead_effort, halstead_error_est, halstead_length, halstead_level, halstead_prog_time, halstead_volume, maintenance_severity, modified_condition_count, multiple_condition_count, node_count, normalized_cylomatic_complexity, num_operands, num_operators, num_unique_operands, num_unique_operators, number_of_lines, percent_comments, loc_total
Một công ti khác là Relink thì sử dụng 26 thông số để đánh giá các module:
AvgCyclomatic, AvgCyclomaticModified, AvgCyclomaticStrict, AvgEssential, AvgLine, AvgLineBlank, AvgLineCode, AvgLineComment, CountLine, CountLineBlank, CountLineCode, CountLineCodeDecl, CountLineCodeExe, CountLineComment, CountSemicolon, CountStmt, CountStmtDecl, CountStmtExe, MaxCyclomatic, MaxCyclomaticModified, MaxCyclomaticStrict, RatioCommentToCode, SumCyclomatic, SumCyclomaticModified, SumCyclomaticStrict, SumEssential
Có thể thấy các đặc trưng được dùng trong hai công ti trên hầu như là khác nhau, nếu để nguyên và lấy dữ liệu của công ti này làm dữ liệu huấn luyện để dự đoán lỗi cho công ti kia thì chắc chắn sẽ không mang lại hiệu quả và có thể phản tác dụng do kết quả dự đoán không đúng, dẫn tới việc cần phải có một cơ chế đồng nhất giúp hai công ti sử dụng được dữ liệu của nhau.
Các dữ liệu sử dụng trong luận văn hầu hết đều là các dữ liệu public, và đã được qua xử lý, trích xuất các thông số cần thiết, do các thông số của các dự án là khác nhau nên trong phần dưới em sẽ trình bày phương pháp giúp khác phục những sự khác biệt đó.