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

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
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ó:
P’ = L’/E’
= (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:
E -> 5.2 (a.S)^ (0.91)
-> 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ệ.
• Tài liệu tham khảo
Nhóm 09 – CNPM K52 Page 11









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 2 – Software metrics, a rigorous and practical approach –
Norman E.Fenton Shari Lawrence Pfleeger
Nhóm 09 – CNPM K52 Page 12