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

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?...1 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

  

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

Hà nội, 09/ 2011

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? 1 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 2 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 đó 3 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 6 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) 8 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ệ 8

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à:

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

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

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

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

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.

phát triển

Đối tượng Người phát triển Khách hàng Tính hữu

dụng

lượng của giai đoạn kiểm thử

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

sản phẩm

phẩm

của sản phẩm, từ đó có thể ước lược được thời gian phát triển

mã nguồn của sản phẩm

sản phẩm

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 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ọ

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:

độ phức tạp trung bình của các tập modul như sau:

Giả sử các modul trong S1 và S2 có độ phức tạp đã đo được với thang M cho ở bảng:

Để 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

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 độ 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ử đó”

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

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)

Ordinal và phép tính median là phép đo hợp lý

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:

Với M’: 1 – 2 – 3 – 4 – 5 – 10 ta có bảng 2:

Modul trong S1 M’ Modul trong S2 M’

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

Với bảng 2: mean(S1)=(1+2+2+3+10)/5=3.6

Mean(S2)=3.14

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

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

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

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:

Sơ đồ minh họa mối quan hệ thực nghiệm của chất lượng:

Để đá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

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à:

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)

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:

Ta có:

- 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:

+ L’ = a1.L + E’ = a2.E

- Nên ta có:

= (a1.L)/(a2.E)

= (a1/a2) L/E

= a L/E

= a.P (với a = a1/a2)

Tức phép đo P cũng là một phép đo 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 là phép đo theo thang tỉ lệ

Thật vậy:

Ta có, với một biến đổi S -> a.S

Khi đó, E ứng với một biến đổi tương đương như sau:

-> 5.2 a.S (với S thực tế là lớn, thì aS^ 0.91 tương đương 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ệ

o Chương 2 – Software metrics, a rigorous and practical approach – Norman E.Fenton Shari Lawrence Pfleeger