BÀI TẬP NHÓM MÔN PHƯƠNG PHÁP VÀ CÔNG CỤ ĐÁNH GIÁ PHẦN MỀM

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG    BÀI TẬP NHÓM MÔN PHƯƠNG PHÁP VÀ CÔNG CỤ ĐÁNH GIÁ PHẦN MỀM Giảng viên hướng dẫn: Thầy Huỳnh Quyết Thắng Nhóm thực hiện: Nhóm 09 – CNPM K52 Nguyễn Thị Lan 20071649 Nguyễn Thị Hoài Phương 20072270 Hà Huy Khánh 20071536 Bùi Thị Hiền Lương 2007 1864 Vũ Thành Trung 20073068 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm Hà nội, 09/ 2011 Contents    1 Contents 2 Câu 4: Chúng ta đã có những ví dụ về đối tượng đo lường từ quan điểm của người quản lý và người phát triển, giờ đây, chúng ta sẽ thảo luận về quan điểm của người dùng. Câu hỏi là đối tượng đo lường nào mà người dùng phần mềm quan tâm? 3 Câu 5: Một phương pháp đánh giá chất lượng phần mềm phổ biến trong công nghiệp là số lỗi được tìm thấy trên nghìn dòng mã nguồn. So sánh tính hữu dụng của phương pháp này cho người sử dụng và cho người phát triển. Vấn đề gì sẽ xảy ra nếu người phát triển chỉ dựa duy nhất vào phép đo này để biểu diễn chất lượng phần mềm 4 Câu 17: Giả sử “Độ phức tạp - Complexity” của các modul phần mềm được xếp theo thứ tự( dựa trên một vài tiêu chí cụ thể) như sau: không đáng kể - đơn giản – vừa phải – phức tạp – rất phức tạp – không thể hiểu nổi. Đặt M là một thang đo bất kỳ tương ứng với dãy độ phức tạp trên, đặt S là tập các modul đã được tính toán với thang đo M đó 5 Câu 18: Ví dụ 2.26 định nghĩa một thuộc tính chất lượng cho trình biên dịch. Hãy vẽ một sơ đồ minh họa mối quan hệ thực nghiệm của chất lượng. Giải thích vì sao không thể tìm được một độ đo cho thuộc tính đó trong tập các số thực mà thỏa mãn điều kiện đại diện. Xác định một phép đo cho một hệ thống số luân chuyển mà thỏa mãn điều kiện đại diện 9 Câu 19: Một phương pháp đo gián tiếp thường được sử dụng để đo hiệu suất của lập trình viên, P = L/E. Trong đó, L là số dòng lệnh, và E là hệ số người/ tháng. Chứng minh rằng mọi sự thay đổi tỷ lệ của P thì đều theo dạng: P’ = aP (với a>0) 10 Câu 20: Chứng minh rằng biểu thức Walston-Felix trong ví dụ 2.31 là một thang đo tỉ lệ 11 Nhóm 09 – CNPM K52 Page 2 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm Câu 4: Chúng ta đã có những ví dụ về đối tượng đo lường từ quan điểm của người quản lý và người phát triển, giờ đây, chúng ta sẽ thảo luận về quan điểm của người dùng. Câu hỏi là đối tượng đo lường nào mà người dùng phần mềm quan tâm? Theo quan điểm của riêng tôi, những vấn đề mà người dùng quan tâm đến (có thể được coi là đối tượng mà chúng ta cần quan tâm thảo luận) là: • Mức độ hoàn chỉnh của chức năng mà sản phẩm cung cấp cho người dùng là bao nhiêu? Như một điều tất yếu, một sản phẩm sẽ được đánh giá cao tùy thuộc vào mức hoàn chỉnh của chức năng mà sản phẩm đó cung cấp cho người sử dụng. Có thể người dùng tùy vào mục đích sử dụng sẽ yêu cầu một số lượng chức năng khác nhau, nhưng bất kể số lượng chức năng yêu cầu nhiều đến đâu, cái người dùng quan tâm đến nhất vẫn là mức độ hoàn chỉnh của chức năng người ta đòi hỏi. • Liệu sản phẩm có dễ sử dụng? Đây là câu hỏi thường gặp nhất của người dùng đặt ra đối với người phát triển. Vấn đề là một sản phẩm dù tốt đến mấy, chức năng hoàn chỉnh đến từng chi tiết, nhưng lại quá rắc rối để sử dụng sẽ khiến cho người dùng rất bực mình và không chấp nhận mua sản phẩm ấy. • Giá thành sản phẩm liệu có phù hợp? Vâng, là giá thành sản phẩm. Câu hỏi này rõ ràng là câu hỏi muôn thuở xuất hiện trong đầu của người sử dụng. Vấn đề kinh tế luôn có tác động lên người dùng: “đắt quá -> không mua”, “rẻ quá -> có vẻ không tốt -> không mua”. Thế nên việc phù hợp giá thành của sản phẩm với thị trường cũng là một đánh giá của người dùng đối với sản phẩm. • Chế độ bảo hành có tốt sau khi mua sản phẩm có được chú trọng không? Ngày nay, một sản phẩm phần mềm không phải chỉ là ký hợp đồng bán xong là chấm dứt mà bao giờ các nhà sản xuất cũng phải có chế độ bảo dưỡng cho khách hàng định kỳ. Việc này vừa khiến cho khách hàng yên tâm sử dụng phần mềm, vừa tạo được uy tín cho nhà sản xuất, cũng được coi như một chiến lược phát triển của nhà sản xuất đối với sản phẩm của mình. Tóm lại, đối với một người dùng thông thường, người ta sử dụng các câu hỏi đặt ra phía trên để đo lường và đánh giá một sản phẩm, vì rõ ràng là người dùng chẳng bao giờ muốn quan tâm đến việc người phát triển sử dụng mô hình kiến trúc nào hay họ lập trình có chuyên nghiệp hay không. Cái họ quan tâm luôn là vấn đề về sản phẩm. • Tài liệu tham khảo Nhóm 09 – CNPM K52 Page 3 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm o Chương 1 – Software metrics, a rigorous and practical approach – Norman E.Fenton Shari Lawrence Pfleeger Câu 5: Một phương pháp đánh giá chất lượng phần mềm phổ biến trong công nghiệp là số lỗi được tìm thấy trên nghìn dòng mã nguồn. So sánh tính hữu dụng của phương pháp này cho người sử dụng và cho người phát triển. Vấn đề gì sẽ xảy ra nếu người phát triển chỉ dựa duy nhất vào phép đo này để biểu diễn chất lượng phần mềm. • So sánh tính hữu dụng của phương pháp này cho người sử dụng và cho người phát triển. Đối tượng Người phát triển Khách hàng Tính hữu dụng - Xác định được chất lượng của giai đoạn kiểm thử. - Xác định xem liệu sản phẩm đã đáp ứng mục tiêu đề ra. Ví dụ: Không có module nào chứa nhiều hơn một lỗi trên 1000 dòng mã nguồn. - Xác định được giá cả sản phẩm. - Biết được giá cả của sản phẩm. - Biết được độ phức tạp của sản phẩm, từ đó có thể ước lược được thời gian phát triển. - Biết được chất lượng của mã nguồn của sản phẩm. - Ước lượng được giá cả sản phẩm • Vấn đề sẽ xảy ra nếu chỉ dựa duy nhất vào phương pháp này để biểu diễn chất lượng phần mềm. o Sự thiếu hụt trách nhiệm giải trình: Lỗi từ các dòng mã nguồn chỉ bắt nguồn từ những vấn đề cơ sở và chỉ chiếm 30-40 % lỗi trong toàn bộ quá trình phát triển phần mềm, lượng phần trăm còn lại là từ các giai đoạn khác trong quá trình phát triển. o Thiếu tính gắn kết với chức năng phần mềm: Một số nhà phát triển phần mềm có kĩ năng tốt có thể phát triển những chức năng hiệu quả hơn với rất ít số dòng mã nguồn. Cùng chức năng đó, nhưng với một nhà phát triển phần mềm ít kinh nghiệm sẽ cần nhiều dòng mã nguồn hơn. o Khác biệt về ngôn ngữ lập trình: với cùng một ứng dụng cố số lượng chức năng tương tự nhau nhưng được phát triển trên hai ngôn ngữ lập trình khac nhau thì số dòng mã nguồn của hai ứng dụng đó sẽ khác biệt khác nhau hoàn toàn. Do đó, nỗ lực tiêu tốn vào phát triển hai ứng dụng cũng sẽ khác biệt nhau. o Sự tiến bộ của công nghệ GUI: Hiện tại người phát triển có thể sử dụng các công cụ kéo thả để phát triển ứng dụng một cách nhanh chóng. Cụ thể, các phần mềm GUI sẽ tự động thiết lập nên mã nguồn Nhóm 09 – CNPM K52 Page 4 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm sản phẩm, vì thế mà số lỗi trên dòng mã nguồn sẽ bị loại bỏ triệt để. Vậy nên phương pháp đánh giá chất lượng qua số dòng mã nguồn không còn phù hợp trong trường hợp này. o Vấn đề phát triển sản phẩm sử dụng nhiêu ngôn ngữ lập trình: Trong môi trường phát triển phần mềm hiện nay, phần mềm thường được phát triển trên nhiều ngôn ngữ lập trình, tùy vào độ phức tạp và yêu cầu của các thành phần phần mềm của phần mềm đó. Do đó, phương pháp đánh giá dựa vào số lỗi trên dòng mã nguồn không còn phù hợp trong trường hợp này. o Vấn đề về sự thiếu hụt chuẩn kiểm toán: Không có một định nghĩa chính xác một dòng mã nguồn là gì. Một dòng mã nguồn có thể là một dòng chú thích, một khai báo dữ liệu, một lời gọi hàm. Do đó, các dòng mã nguồn có vai trò hoàn toàn khác nhau, vậy nên việc sử dụng phép đo sỗ lỗi trên mã nguồn là không hợp lý. o Vấn đề tâm lý: Việc sử dụng phương pháp đánh giá dựa vào số dòng mã nguồn có thể bị các lập trình viên lợi dụng. Cụ thể, họ có thể viết các dòng mã nguồn đơn giản hoặc tăng số lượng dòng mã nguồn lên đẻ tăng đanh giá về nỗ lực làm việc của họ. • Tài liệu tham khảo o Chương 1 – Software metrics, a rigorous and practical approach – Norman E.Fenton Shari Lawrence Pfleeger o Source line of code – Wikipedia - http://en.wikipedia.org/wiki/Source_lines_of_code Câu 17: Giả sử “Độ phức tạp - Complexity” của các modul phần mềm được xếp theo thứ tự( dựa trên một vài tiêu chí cụ thể) như sau: không đáng kể - đơn giản – vừa phải – phức tạp – rất phức tạp – không thể hiểu nổi. Đặt M là một thang đo bất kỳ tương ứng với dãy độ phức tạp trên, đặt S là tập các modul đã được tính toán với thang đo M đó. i. Chỉ ra độ phức tạp trung bình của các modul trong tập S theo một cách hợp lý. ii. Giải thích tại sao tính trung bình các giá trị M là vô nghĩa. Để lý giải nó bạn nên đưa ra một trường hợp chứng minh điều này. iii. Đưa ra 2 tiêu chí có thể dùng để đánh giá độ phức tạp của một modul. Trả lời: i. Giả sử ta có 2 tập S1 gồm 5 modul, },,,,{ 15141312111 sssssS = và S2 gồm 7 modul, },,,,,,{ 272625242322212 sssssssS = . Sử dụng thang đo Ordinal để so sánh độ phức tạp trung bình của các tập modul như sau: M Độ phức tạp 1 Không đáng kể Nhóm 09 – CNPM K52 Page 5 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm 2 Đơn giản 3 Vừa phải 4 Phức tạp 5 Rất phức tạp 6 Không thể hiểu nổi Giả sử các modul trong S1 và S2 có độ phức tạp đã đo được với thang M cho ở bảng: Modul trong S1 M Modul trong S2 M s11 1 s21 1 s12 2 s22 3 s13 2 s23 3 s14 3 s24 3 s15 6 s25 4 s26 4 s27 4 Để tính độ phức tạp trung bình của các modul trong hai tập S1 và S2 ta sử dụng giá trị median để xác định. Median của một tập n số là giá trị trung bình chia đôi tập n phần tử đó thành 2 tập sao cho số phần tử của tập này bằng số phần tử của tập kia. Dựa vào bảng giả thiết ta tính được: Median(S1)=2 và Median(S2)=3  Độ phức tạp của các modul trong S2 lớn hơn độ phức tạp của các modul trong S1.  Chứng minh phép đo này là hợp lý: Ta sẽ chứng minh phép đo là hợp lý theo định nghĩa phép đo hợp lý sau: “Một phép đo là hợp lý nếu như giá trị đúng của nó là bất biến trong mọi trường hợp thay đổi thang đo” . Ta có định nghĩa thang đo Ordinal như sau: M và M’ là hai thang đo tương ứng thuộc thang đo Ordinal nếu: M(x)>M(y) khi và chỉ khi M’(x)>M’(y). Ta sẽ chứng minh bổ đề sau”Với 1 tập S gồm n lẻ modul {si}n, nếu si là giá trị median của S theo thang đo M thì si cũng là median của S theo thang đo M’, nếu n chẵn thì giá trị median với thang đo M là trung bình cộng của độ Nhóm 09 – CNPM K52 Page 6 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm phức tạp của 2 phân tử liền nhau si và s(i+1) thì khi chuyển sang M’ nó vẫn là trung bình cộng của độ phức tạp của 2 phần tử đó”. • Chứng minh: giả sử S={s1,s2,…sn} đã sắp xếp theo chiều tăng dần độ phức tạp đo theo thang M, giả sử kết quả đo độ phức tạp tương ứng là m1<m2<m3<…mn. +Nếu n lẻ thì median chính là độ phức tạp của phần tử s((n+1)/2). Khi chuyển sang thang M’ tương ứng ta cũng sẽ thu được dãy độ phức tạp tương ứng của dãy S ban đầu là m’1<m’2<m’3<…m’n  median vẫn là độ phức tạp của phần tử s((n+1)/2) +Nếu n chẵn ta sử dụng phần tử giả định s((n+1)/2) và độ phức tạp của phần tử này chính là giá trị median  theo định nghĩa M và M’ thì ta vẫn có khẳng định như n lẻ. Tức là median khi đo với M và M’ vẫn là phần tử giả định Giả sử ta có 2 tập cần so sánh độ phức tạp với thang Ordinal: M và M’ là hai thang đo tương ứng thuộc thang đo Ordinal S1={s11,s12,…s1n} giả sử đo được độ phức tạp theo M là tập giá trị M1={m11,m12,…m1n} và m1i là giá trị median của S1 với M S2={s21,s22,…s2n} giả sử đo được độ phức tạp theo M là tập giá trị M2={m21,m22,…m2n} và m2j là giá trị median của S2 với M  Theo bổ đề trên phần tử s1i tương ứng với độ phức tạp m1i là phần tử mang giá trị median của tập S1 cũng sẽ chính là phần tử mang giá trị median của tập S1 nếu chuyển sang thang đo tương ứng M’. Do đó hiển nhiên theo định nghĩa M và M’ ta có M(s1i)>M(s2j) thì M’(s1i)>M’(s2j)  Kết luận: Vậy phép đo độ phức tạp trung bình của 1 tập modul sử dụng thang đo Ordinal và phép tính median là phép đo hợp lý. ii. Chứng minh phép đo độ phức tạp trung bình sử dụng phép mean (trung bình cộng các sô) là không hợp lý. Ta lấy luôn ví dụ trong phần i: Với thang đo M ta có bảng 1: Modul trong S1 M Modul trong S2 M s11 1 s21 1 s12 2 s22 3 s13 2 s23 3 s14 3 s24 3 s15 6 s25 4 s26 4 Nhóm 09 – CNPM K52 Page 7 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm s27 4 Với M’: 1 – 2 – 3 – 4 – 5 – 10 ta có bảng 2: Modul trong S1 M’ Modul trong S2 M’ s11 1 s21 1 s12 2 s22 3 s13 2 s23 3 s14 3 s24 3 s15 10 s25 4 s26 4 s27 4 Khi đó với bảng 1: mean(S1)=(1+2+2+3+6)/5=2.8 Mean(S2)=(1+3+3+3+4+4+4)/7=3.14  Mean(S1)<mean(S2) (1) Với bảng 2: mean(S1)=(1+2+2+3+10)/5=3.6 Mean(S2)=3.14  Mean(S1)>mean(S2)  (1) không còn đúng  Kết luận: phép đo mean trong trường hợp này là không hợp lý. iii. 2 tiêu chí để đo độ phức tạp của modul: Ta có thể sử dụng 2 tiêu chí sau để đánh giá độ phức tạp của một modul: + Số dòng lệnh +Thời gian kiểm thử modul  Đây là 2 số đo định lượng nên có thể áp dụng đúng thang đo trên. Với định nghĩa độ phức tạp như sau: + Số dòng lệnh modul A lớn hơn số dòng lệnh modul B tương ứng với việc kết luận modul A phức tạp hơn modul B. Vì số dòng lệnh modul A sẽ vẫn lớn hơn số dòng lệnh modul B trong mọi thang đo nên kết luận vẫn đúng trong mọi thang đo. +Thời gian kiểm thử modul A dài hơn thời gian kiểm thử modul B tương ứng với v Nhóm 09 – CNPM K52 Page 8 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm việc kết luận modul A phức tạp hơn modul B. Vì thời gian kiểm thử modul A sẽ vẫn lớn hơn thời gian kiểm thử modul B trong mọi thang đo nên kết luận vẫn đúng trong mọi thang đo. • Tài liệu tham khảo o Chương 2 – Software metrics, a rigorous and practical approach – Norman E.Fenton Shari Lawrence Pfleeger Câu 18: Ví dụ 2.26 định nghĩa một thuộc tính chất lượng cho trình biên dịch. Hãy vẽ một sơ đồ minh họa mối quan hệ thực nghiệm của chất lượng. Giải thích vì sao không thể tìm được một độ đo cho thuộc tính đó trong tập các số thực mà thỏa mãn điều kiện đại diện. Xác định một phép đo cho một hệ thống số luân chuyển mà thỏa mãn điều kiện đại diện. Trả lời: Bảng dữ liệu thu thập được của 4 trình biên dịch: Speed Resource A 45 200 B 20 400 C 30 300 D 10 600 Sơ đồ minh họa mối quan hệ thực nghiệm của chất lượng: Nhóm 09 – CNPM K52 Page 9 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm Để đánh giá chất lượng trình biên dịch, ta không thể đánh giá trực tiếp bằng một độ đo trực tiếp mà phải thông qua 2 thông số thuộc tính con là speed và resource. Xét 2 trình biên dịch, coi một trình biên dịch là tốt hơn nếu lượng tài nguyên của RAM cần thiết ít hơn và tốc độ (lượng dòng code trong một đơn vị thời gian) là nhanh hơn. Như trong 4 trình biên dịch trên thì A tốt hơn C, C tốt hơn B, và D tốt hơn A. Xét một trình biên dịch E có speed = 35, resource = 500. So sánh E với B (speed = 20, resource = 400). Có 3 trường hợp có thể xảy ra là: - E tốt hơn B - B tốt hơn E - E và B tốt như nhau Dễ dàng nhận thấy mệnh đề 3 không thể đúng. Nếu mệnh đề 1 đúng, mâu thuẫn với việc E tốn nhiều tài nguyên hơn B. Nếu mệnh đề 2 đúng, mâu thuẫn với việc E có tốc độ cao hơn B. Điều đó cho thấy, ta không thể xác định một độ đo cho thuộc tính biểu diễn trên tập số thực mà thỏa mãn điều kiện đại diện. Lí do là chúng ta đã xem xét trên một hệ thống số quá hẹp. Khi sắp xếp các thực thể, ta so sánh từng phần một và như vậy, không thể xét được hết các trường hợp quan hệ có thể xảy ra nếu chỉ sử dụng một độ đo trên tập số thực. Phép đo cho thuộc tính thỏa mãn điều kiện đại diện phải được ánh xạ trên bộ R*R. Độ đo m đối với các trình biên dịch dựa trên cặp tốc độ, tài nguyên: M(trình biên dịch) = (speed, resource) m(A) = (45, 200) m(B) = (20, 400) m(C) = (30, 300) m(D) = (10, 600) • Tài liệu tham khảo o Chương 2 – Software metrics, a rigorous and practical approach – Norman E.Fenton Shari Lawrence Pfleeger Câu 19: Một phương pháp đo gián tiếp thường được sử dụng để đo hiệu suất của lập trình viên, P = L/E. Trong đó, L là số dòng lệnh, và E là hệ số người/ tháng. Chứng minh rằng mọi sự thay đổi tỷ lệ của P thì đều theo dạng: P’ = aP (với a>0). Trả lời: Nhóm 09 – CNPM K52 Page 10 [...].. .Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm Ta có: 2 - Số dòng lệnh L và hệ số người/ tháng E đều là đo theo kiểu thang đo tỉ lệ, do đó mọi sự biến đổi L thành L’ và E thành E’ đều theo dạng: 2011 + L’ = a1.L + E’ = a2.E - Nên ta có: P’ = L’/E’ = (a1.L)/(a2.E) = (a1/a2) L/E... aS) -> a.E Vậy tức là, biểu thức Walston-Felix là một phép đo theo thang đo tỉ lệ • Tài liệu tham khảo Nhóm 09 – CNPM K52 Page 11 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm o Chương 2 – Software metrics, a rigorous and practical approach – Norman E.Fenton Shari Lawrence Pfleeger 2 2011 Nhóm 09 – CNPM K52 Page 12 ... theo thang tỉ lệ (ratio scale) Câu 20: Chứng minh rằng biểu thức Walston-Felix trong ví dụ 2.31 là một thang đo tỉ lệ Trả lời: Biểu thức Walston-Felix như sau: E = 5.2 S^(0.91) Có ý kiến cho rằng, cả E và S đều được thể hiện theo thang đo tỉ lệ, nhưng biểu thức trên lại không bảo toàn sự biến đổi S -> a.S, do đó phép đo này là vô nghĩa Nhưng trong thực tế với hầu hết các trường hợp sử dụng, thì đây chính . chất lượng: Nhóm 09 – CNPM K52 Page 9 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm Để đánh giá chất lượng trình biên dịch, ta không thể đánh giá trực tiếp. nhanh chóng. Cụ thể, các phần mềm GUI sẽ tự động thiết lập nên mã nguồn Nhóm 09 – CNPM K52 Page 4 2 0 1 1 2 Bài tập nhóm môn Phương pháp và công cụ đánh giá phần mềm sản phẩm,. KHOA HÀ NỘI VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG    BÀI TẬP NHÓM MÔN PHƯƠNG PHÁP VÀ CÔNG CỤ ĐÁNH GIÁ PHẦN MỀM Giảng viên hướng dẫn: Thầy Huỳnh Quyết Thắng Nhóm thực hiện: Nhóm 09 – CNPM