Tài liệu De_tai_danh_gia_do_tin_cay_phan_mem_huong_doi_tuong

Lời cảm ơn Để có được đồ án tốt nghiệp này, tôi xin bày tỏ lòng biết ơn sâu sắc tới tập thể các thầy giáo, cô giáo trường Đại học Bách khoa Hà Nội nói chung và khoa Công nghệ thông tin nói riêng đã tận tình giảng dạy truyền đạt cho tôi những kiến thức, kinh nghiệm quý báu trong suốt những năm học vừa qua. Tôi xin chân thành cảm ơn thầy giáo tiến sĩ Huỳnh Quyết Thắng, bộ môn Công nghệ Phần mềm, khoa Công nghệ Thông tin, trường Đại học Bách khoa Hà Nội đã khuyến khích, góp ý và rất tận tình hướng dẫn tôi trong suốt quá trình làm đồ án. Nhờ sự quan tâm chỉ bảo và những ý kiến đóng góp quý báu của thầy, tôi mới có thể hoàn thành đồ án này. Trong thời gian sửa chữa hoàn thiện đồ án, tôi đã nhận được sự chỉ bảo tận tình của thầy giáo tiến sĩ Nguyễn Ngọc Bình, trưởng bộ môn Công nghệ Phần mềm, khoa Công nghệ Thông tin, trường Đại học Bách khoa Hà Nội. Tôi xin chân thành cảm ơn thầy đã dành cho tôi sự quan tâm và những ý kiến quý báu để tôi có thể hoàn thành đồ án này. Đồ án này cũng không thể hoàn thành nếu thiếu sự hỗ trợ về tư liệu và cơ sở vật chất từ phía trung tâm xuất khấu phần mềm Fsoft-fpt Hà Nội, tôi xin chân thành cảm ơn anh Phan Phương Đạt đã khuyến khích, động viên, giúp đỡ và tạo mọi điều kiện để tôi hoàn thành đồ án này. Cuối cùng, xin chân thành cảm ơn gia đình và bạn bè, những người đó luụn ở bên tôi trong suốt những năm học vừa qua. 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 Đ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......................................................................24 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......................................................................................27 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..............................28 Kết luận chương 1:.....................................................................................28 CHƯƠNG 2: PHÉP ĐO PHẦN MỀM HƯỚNG ĐỐI TƯỢNG...30 2.1. Bộ các phép đo CK............................................................................31 2.1.1 Cơ sở lý thuyết của các phép đo CK...............................................31 a. Cơ sở lý thuyết phát triển phần mềm hướng đối tượng........................31 b. Cơ sở lý thuyết đo..................................................................................32 c. Một số khái niệm...................................................................................33 2.1.2 Các tính chất của phép đo hướng đối tượng..................................35 2.1.3 Các phép đo trong hệ đo CK............................................................36 1. WMC (Weight Method per Class).........................................................36 2. DIT (Depth of Inheritance Tree)..........................................................37 3. NOC (Number Of Children)..................................................................37 4. CBO (Coupling Between Object)..........................................................38 5. RFC (Responce For a Class).................................................................38 6. LCOM (Lack of Cohesion in Methods)................................................39 2.1.4 Tổng kết về các phép đo CK:...........................................................39 2.1.5 Một ví dụ về các phép đo CK..........................................................40 2.2 Mô hình đánh giá chất lượng phần mềm hướng đối tượng. 42 Mô hình REBOOT (ReusE Based on Object Oriented Technology)..........42 Mô hình QMOOD (Quality Model for Object Oriented Design).................44 Kết luận chương 2:.....................................................................................47 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 HƯỚNG ĐỐI TƯỢNG......48 3.1 Phân tích các yêu cầu.........................................................................48 3.2 Các chức năng chính của chương trình.......................................51 3.3 Cơ sở dữ liệu của chương trình......................................................51 3.4 Chọn lựa công cụ thực hiện.............................................................52 3.5 Xây dựng chương trình.................................................................53 a. Mô tả cơ sở dữ liệu....................................................................................53 b. Giao diện của chương trình......................................................................55 c. Xây dựng các chức năng của chương trình..............................................55 3.6 Giới thiệu chương trình:...............................................................60 Mô tả chương trình nguồn:............................................................................60 Mô tả giao diện chương trình:...................................................................62 CHƯƠNG 4: MỘT SỐ KẾT QUẢ ĐO PHẦN MỀM HƯỚNG ĐỐI TƯỢNG....................................................................................................68 4.1 Kết quả các phép đo CK...................................................................69 4.1.1. Kết quả độ đo LCOM..........................................................................70 4.1.2 Kết quả độ đo DIT................................................................................71 4.1.3. Kết quả độ đo CBO.............................................................................72 4.1.4 Kết quả độ đo NOC..............................................................................73 4.1.5 Kết quả độ đo RFC...............................................................................75 4.1.6 Kết quả độ đo WMC.............................................................................76 4.1.7. Tổng hợp kết quả các độ đo CK..........................................................78 4.1.8 Quan hệ ảnh hưởng giữa các độ đo CK và các thuộc tính khác..........79 4.2 Kết quả đo sử dụng mô hình QMOOD.......................................82 4.2.1. Quá trình đo sử dụng mô hình QMOOD.......................................82 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 ........................................................................................................................85 Nhận xét đánh giá về các kết quả đo thực nghiệm:........................86 KẾT LUẬN.......................................................................................................88 TÀI LIỆU THAM KHẢO...........................................................................90 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......................................................41 Hình 2.2: Mô hình REBOOT.................................................................................43 Hình 2.3: Mô hình QMOOD.................................................................................46 Hình 3.1: Quy trình đo phần mềm hướng đối tượng.............................................49 Hình 3.2: Sơ đồ hoạt động của chương trình........................................................50 Hình 3.3: Các chức năng chính của chương trình.................................................51 Hình 3.4: Các bảng trong cơ sở dữ liệu của chương trình....................................52 Hình 3.5: Chức năng nhập dữ liệu của chương trình............................................63 Hình 3.6: Chức năng tính toán và hiển thị độ đo trên mô hình.............................64 Hình 3.7: Chức năng tạo mới và sửa đổi mô hình................................................65 Hình 3.8: Chức năng mở CSDL............................................................................66 Hình 3.9: Chức năng phân tích kết quả đo............................................................67 Hình 4.1: Kết quả độ đo LCOM............................................................................71 Hình 4.2: Kết quả độ đo DIT................................................................................72 Hình 4.3: Kết quả độ đo CBO..............................................................................73 Hình 4.4: Kết quả độ đo NOC..............................................................................74 Hình 4.5: Kết quả độ đo RFC................................................................................76 Hình 4.6: Kết quả độ đo WMC.............................................................................77 Hình 4.7: Biểu đồ độ đo CK của các phần mềm...................................................78 Hình 4.8: Dự đoán thuộc tính chất lượng dựa trên các độ đo CK........................81 Hình 4.9: Kết quả đo một số thuộc tính của mô hình QMOOD...........................84 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...................40 Bảng 2.2: Các dạng hàm chuẩn hóa độ đo............................................................44 Bảng 2.3: Các tiêu chuẩn và độ đo trong mô hình QMOOD................................45 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 của mô hình QMOOD.........................................................................................................46 Bảng 3.1: Một số công cụ đo phần mềm hướng đối tượng...................................49 Bảng 3.2: Công thức tính tham số cho các dạng hàm chuẩn hóa.........................58 Bảng 4.1: Danh sách các dự án được đo...............................................................69 Bảng 4.2: Tổng cộng số lớp các dự án được đo....................................................69 Bảng 4.3: Kết quả độ đo CK của các phần mềm...................................................78 Bảng 4.4: Hệ số tương quan giữa các độ đo CK và các chỉ số chất lượng..........80 Bảng 4.5: Các hệ số của phương trình tuyến tính biểu diễn phụ thuộc giữa thuộc tính chất lượng và độ đo................................................................................81 Bảng 4.6: Kết quả các độ đo của mô hình QMOOD............................................82 Bảng 4.7: Lựa chọn ngưỡng cho các hàm chuẩn hóa các độ đo...........................83 Bảng 4.8: Ngưỡng cho các hàm chuẩn hóa các độ đo QMOOD..........................83 Bảng 4.9: Kết quả đo một số thuộc tính của mô hình QMOOD...........................84 Bảng 4.10: Hệ số tương quan giữa các thuộc tính của mô hình QMOOD với các thuộc tính chất lượng khác.............................................................................85 Bảng 4.11: Hệ số tương quan giữa các độ đo và các chỉ số chất lượng...............86 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.....86 BẢNG GHI CHÚ CÁC THUẬT NGỮ Viết tắt ADO Viết đầy đủ Active Data Object ANA API CBO CIS Average Number of Ancesters Application Programming Interface Cohesion Among Methods in Class Coupling Between Object class Class Interface Size CK Chidamber, Kemerer COCOMO Constructive Cost Model CSDL DAM Cơ sở dữ liệu Data Access Metric DCC Direct Class Coupling DIT DSC FCM Depth of Inheritance Tree Design Size in Classes Factor-Criteria-Metrics GNU GNU Library General Public License International Standard Organization CAM ISO 9126 JBOOMT JDK LCOM LOC MFA Jade Bird Object Oriented Metric Tool Java Developer Kit Lack of Cohesion among Methods Lines of code Measure of Functional Abstraction Giải nghĩa Đối tượng để truy cập cơ sở dữ liệu Trung bình số các lớp cha Giao diện lập trình ứng dụng Tính cố kết giữa các phương thức trong cùng một lớp Độ kết dính giữa các lớp Kích thước giao diện lớp (số phương thức public) Bộ các phép đo hướng đối tượng do Chidamber, Kemerer đề xuất [6] Mô hình ước tính chi phí cho các dự án phần mềm Khả năng truy cập dữ liệu (tỷ lệ số thuộc tính public) Số lớp có tính kết dính với một lớp Độ sâu cây thừa kế Số lớp của chương trình Mô hình nhân tố-tiêu chuẩn-độ đo để đánh giá chất lượng phần mềm Thư viện C++ của cộng đồng mã nguồn mở 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ế Công cụ đo phần mềm hướng đối tượng Thư viện lập trình Java của Sun Microsystem Độ thiếu cố kết giữa các phương thức (trong cùng 1 lớp) Số dòng mã lệnh Độ đo mức độ sử dụng thừa kế của một lớp MFC Microsoft Foundation Class MFM Measure of Functional MOA MTBF MTTF MTTR NOC NOH NOM Modularity Measure of Aggregation Mean Time Between Failure Mean Time To Failure Mean Time To Repair Number Of Children Number Of Hierarchies Number of Methods NOP ODBC OLEDB QMOOD REBOOT RFC STL WMC Number of Polymorphic Methods Open Database Connectivity Thư viện lập trình C++ của Microsoft Độ đo về tính độc lập chức năng Sự tổ hợp giữa các lớp Thời gian giữa các sai hỏng Thời gian đến sai hỏng Thời gian để sửa chữa Số con trực tiếp của một lớp Số các mức phân cấp Số phương thức trong lớp (độ phức tạp của lớp) Số phương thức đa hình Đối tượng để truy cập cơ sở dữ liệu Object Linking Embedding – Đối tượng để truy cập cơ sở dữ Database liệu Quality Model for Object Mô hình chất lượng cho phần Oriented Design mềm hướng đối tượng ReusE Based on Object Oriented Mô hình sử dụng lại cho phần Technology mềm hướng đối tượng 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 đó) Standard Template Library Thư viện lập trình C++ cung cấp các tính năng mở rộng Weight Metric per Class Độ phức tạp của một lớp 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. 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. 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. Ví dụ: Chương trình 100 Số câu lệnh X 3000 Số byte 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. 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: 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ệ R1 “là cỳ phỏp”, R2 “là logic”, R3 “là đổ vỡ hệ thống”. Giả thiết rằng với mọi xC thì x là R1, R2, hoặc R3. 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 R4 “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. R4 gồm các cặp sai hỏng (x, y) trong đó hoặc: i)xR3 và yR2 hay R1, ii) xR2 và yR1. 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’ = {R1, R2, R3, R4}. 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’)  R5 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’’ = {R1, R2, R3, R4, R5}. 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 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 R1) 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ệ R1, R2, R3 thành các quan hệ P1, P2, P3 đối với các số trong đó P1 là quan hệ “là 6”, P2 là quan hệ “là 2” và P3 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 R4. Quan hệ P4 đươ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ự 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. 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 Nhiệm vụ đo người Nhà quản Chi phí cho các pha của dự án lý Năng suất (năng lực sản suất) của nhân viên Chất lượng phần mềm được sản xuất Mục đích Kiểm soát chi phí nhằm thu được lợi nhuận Trả tiền công cho nhân viên 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ư Quá trình: thay đổi ở pha thiết kế, lỗi ở Kiểm soát tiến triển của phần mềm pha kiểm tra... hệ thống. Cụ thể hóa các yêu cầu đo từ nhà quản Thông báo cho người lý và tiến hành đo: lỗi / yêu cầu, kích quản lý để có những thước, chi phí, ... 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 (a) Mức độ hoàn thành đúng thời gian (Timeliness) (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). 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 N1 = tổng số toán tử 2 = số toán hạng phân biệt N2 = tổng số toán hạng Độ dài của chương trình P được định nghĩa là N=N1+N2. 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: 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 N1 = 51N N2 = 42 N = N1 + N2 = 93  = 1 + 2 = 27 = 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. 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 : 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ố ai, bi, ci, di đượ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 ai bi ci Nhỏ 2.4 1.05 2.5 Trung bình 3.0 1.12 2.5 Lớn 3.6 1.20 2.5 Bảng 1.2: Các hệ số trong mô hình COCOMO di 0.38 0.35 0.32 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)]