Nghiên cứu các độ đo phần mềm và một số triển khai đánh giá
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.46 MB, 137 trang )
..
LƯƠNG THANH Bình
bộ giáo dục và đào tạo
trường đại học bách khoa hà nội
---------------------------------------
luận văn thạc sĩ khoa học
công nghệ THÔNG
học
ngành : công nghệ THÔNG TIN
NGHIấN CU CC O PHN MM
V MT S TRIN KHAI, NH GI
LƯƠNG THANH BèNH
2005 - 2007
Hà Nội
2007
Hµ Néi 2007
Luận văn tốt nghiệp CNTT 2005-2007
2
Mc lc
Mc lc ................................................................................................................... 2
Danh mục hình vẽ .................................................................................................. 5
Danh mục bảng....................................................................................................... 7
Danh mục từ viết tắt ............................................................................................... 8
LỜI GIỚI THIỆU ................................................................................................. 10
CHƯƠNG 1: TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ ĐỘ ĐO
CHẤT LƯỢNG PHẦN MỀM ............................................................................. 13
1.1.
Chất lượng phần mềm ............................................................................ 13
1.1.1.
Chất lượng-những quan điểm chung ............................................... 13
1.1.2.
Định nghĩa ....................................................................................... 15
1.1.3.
Đánh giá kiến trúc phần mềm.......................................................... 18
1.1.4.
Các chuẩn chất lượng phần mềm .................................................... 19
1.2.
Tại sao cần độ đo phần mềm .................................................................. 22
1.3.
Độ đo phần mềm .................................................................................... 25
1.3.1.
Định nghĩa độ đo phần mềm ........................................................... 25
1.3.2.
Phân loại các thang đo ..................................................................... 26
1.3.3.
Lịch sử ............................................................................................. 28
1.3.4.
Hướng nghiên cứu trong tương lai .................................................. 30
1.4.
Khảo sát hiện trạng sử dụng độ đo phần mềm ở Việt Nam .................. 31
1.5.
Kết chương ............................................................................................. 33
CHƯƠNG 2: ĐỘ ĐO CHO MẪU THIẾT KẾ .................................................... 34
2.1.
Công nghệ phần mềm dựa theo thành phần ........................................... 34
2.2.
Mu thit k ............................................................................................ 35
Lương Thanh Bình
2
Luận văn tốt nghiệp CNTT 2005-2007
2.3.
3
Mu thit k trong kin trúc phần mềm ................................................. 37
2.4. Các mẫu thiết kế cơ sở của GoF ................................................................ 46
2.4.1.
Creational Patterns........................................................................... 46
2.4.2.
Structural Patterns ........................................................................... 51
2.4.3.
Behavioral pattern ........................................................................... 56
2.5. Các độ đo hướng đối tượng gốc ................................................................ 63
2.5.1. Các độ đo hướng đối tượng cơ sở ....................................................... 63
2.5.2. Các độ đo dựa theo thành phần ........................................................... 65
2.6. Kết chương................................................................................................. 68
CHƯƠNG 3 : ĐÁNH GIÁ KIẾN TRÚC PHẦN MỀM DỰA TRÊN MẪU
THIẾT KẾ ............................................................................................................ 69
3.1. Một số nghiên cứu về độ đo cho mẫu thiết kế ........................................... 69
3.2. Nhu cầu sử dụng các mẫu phức hợp .......................................................... 72
3.2. Nền tảng và những nghiên cứu liên quan .................................................. 74
3.3. Phương pháp được đề xuất ........................................................................ 77
3.4. Kết chương................................................................................................. 90
CHƯƠNG 4. THỬ NGHIỆM VÀ ĐÁNH GIÁ .................................................. 91
4.1. Giới thiệu chung ........................................................................................ 91
4.2. Chức năng .................................................................................................. 93
4.3. Thử nghiệm công cụ ................................................................................ 101
4.4. Kết chương............................................................................................... 103
CHƯƠNG 5: KẾT LUẬN ................................................................................. 105
5.1. Đánh giá kết quả đạt được của luận văn .................................................. 105
5.2. Hướng phát triển của luận văn ................................................................. 106
Danh mc tham kho ......................................................................................... 108
Lương Thanh Bình
3
Luận văn tốt nghiệp CNTT 2005-2007
4
PH LC: QUY TRèNH ĐO ..................................................................... 113
1. Ý nghĩa của quy trình độ đo..................................................................... 113
2. Quy trình độ đo 8 bước [SPC05] ............................................................... 113
L¬ng Thanh B×nh
4
Luận văn tốt nghiệp CNTT 2005-2007
5
Danh mc hỡnh v
Hỡnh 1.1: Quan hệ giữa yêu cầu và các đặc tính chất lượng................................ 16
Hình 1.2: Thế nào là độ đo phần mềm ................................................................. 25
Hình 2.1: Hai mẫu thiết kế cửa ra vào ................................................................. 35
Hình 2.2: Các thành phần trong kiến trúc phần mềm .......................................... 38
Hình 2.3: Quan hệ tĩnh trong OMT...................................................................... 39
Hình 2.4: Khung nhìn trong kiến trúc phần mềm ................................................ 39
Hình 2.5: Mơ hình Abstract Factory Pattern ........................................................ 47
Hình 2.6: Mơ hình Builder pattern ....................................................................... 48
Hình 2.7: Mơ hình Factory Method Pattern ......................................................... 49
Hình 2.8: Mơ hình Prototype Pattern ................................................................... 50
Hình 2.9: Mơ hình Singleton Pattern ................................................................... 51
Hình 2.10: Mơ hình Adapter Pattern .................................................................... 52
Hình 2.11: Mơ hình Bridge Pattern ...................................................................... 52
Hình 2.12: Mơ hình Composite Pattern ............................................................... 53
Hình 2.13: Mơ hỡnh Faỗade Pattern ..................................................................... 54
Hỡnh 2.14: Mụ hỡnh Proxy Pattern ....................................................................... 54
Hình 2.15: Mơ hình Decorator Pattern................................................................. 55
Hình 2.16: Mơ hình Flyweight ............................................................................. 56
Hình 2.17: Mơ hình State Pattern......................................................................... 57
Hình 2.18: Mơ hình Strategy Pattern ................................................................... 57
Hình 2.19: Mơ hình Template Method Pattern .................................................... 58
Hình 2.20: Mơ hình Visistor Pattern .................................................................... 58
Hình 2.21: Mơ hình Chain of Responsibility Pattern .......................................... 59
Lương Thanh Bình
5
Luận văn tốt nghiệp CNTT 2005-2007
6
Hỡnh 2.22: Mụ hỡnh Iterator Pattern ..................................................................... 60
Hình 2.23: Mơ hình Mediator Pattern .................................................................. 60
Hình 2.24: Mơ hình Mementor Pattern ................................................................ 61
Hình 2.25: Mơ hình Observer Pattern .................................................................. 61
Hình 2.26: Mơ hình Command Pattern ................................................................ 62
Hình 2.27: Mơ hình Command Pattern ................................................................ 63
Hình 3.1: Các pha trong quá trình xác định một mẫu phức hợp .......................... 79
Hình 3.2: Thiết kế mẫu (MVC) ............................................................................ 84
Hình 3.3: Biểu diễn đồ họa của các mức chồng mẫu........................................... 88
Hình 4.1: Mơ hình hoạt động của PM4J .............................................................. 92
Hình 4.2: Giao diện PM4J .................................................................................... 94
Hình 4.3: Chức năng phân tích trong PM4J......................................................... 95
Hình 4.4: Các độ đo hướng đối tượng cho class .................................................. 97
Hình 4.5: Các độ đo hướng đối tượng cho thành phần ........................................ 98
Hình 4.6: Chức năng đo cho mẫu thiết kế............................................................ 99
Hình 4.7: Các độ đo độ phủ mẫu ....................................................................... 100
Hình 4.8: Các độ đo độ chồng mẫu .................................................................... 101
Hình 4.9: Thiết kế thử nghiệm BoF ................................................................... 101
Hình 4.10: Phân tích các thành phần trong BoF ................................................ 102
Bảng 4.4: Giá trị phủ mẫu cho BoF ................................................................... 103
Bảng 4.4: Giá trị phủ mẫu cho BoF ................................................................... 103
L¬ng Thanh B×nh
6
Luận văn tốt nghiệp CNTT 2005-2007
7
Danh mc bng
Bng 3.1: Cỏc giá trị độ phủ................................................................................. 84
Bảng 3.2: Các giá trị độ chồng mẫu cho thiết kế mẫu ......................................... 86
Bảng 3.3: Các thnh t chng mu ...................................................................... 87
Lương Thanh Bình
7
Luận văn tốt nghiệp CNTT 2005-2007
Danh mc t vit tt
STT Từ viết tắt
1
BoF
8
Từ đầy đủ
Bill of Material Factory
Giải thích
Mẫu thiết kế của người
thử nghiệm
2
CBO
Coupling between object classes
Tính ghép cặp giữa hai
lớp đối tượng
3
DIT
Depth of Inheritance Tree
Độ sâu cây thừa kế
4
EXTCBO
Coupling between object classes
Tính ghép cặp mở rộng
External
giữa hai lớp đối tượng
5
FP
Function Point
Điểm hàm
6
GoF
Gang of Four
Nhóm tác giả 23 mẫu
thiết kế phần mềm cơ
sở
7
GQM
Goal/Question/Metric
Mục đích/Câu hỏi/Độ
đo
8
9
10
IEEE
ISO
LCOM
Institute of Electrical and
Viện kỹ thuật điện và
Electronic Engineers
điện tử Hoa Kỳ
International Standard
Tổ chức Chuẩn hóa
Organization
quốc tế
Lack of cohesion in methods
Thiếu độ gắn kết giữa
các phương thức
11
LOC
Line of Code
Số dòng mã nguồn
12
MVC
Model View Controller
Mẫu thiết kế phn mm
tng tỏc
Lương Thanh Bình
8
Luận văn tốt nghiệp CNTT 2005-2007
13
NASA
9
National Aeronautics and Space
C quan Hàng không
Administration
và Vũ trụ Hoa Kỳ
14
NC
Number of Classes
Số lớp
15
NOC
Number of Children
Số thành phần con
16
NOM
Number of methods
Số Phương thức
17
OMT
Object Modeling Technique
Kỹ thuật Mơ hình hóa
18
RFC
Response for a class
Đáp ứng của một lớp
19
RFCOM
Response Set for a Component
Tập đáp ứng của một
thành phần
20
RTTI
RuntimeIdentifier
Thời gian thực thi
21
SDC
Software Development Cost
Mơ hình đánh giá chi
phí phát triển phần
mềm
22
SEl
Software Engineering laboratory
Phịng thí nghiệm Cơng
nghệ phần mềm
23
SLOC
Source Line of Code
Số dịng mã nguồn
24
TQM
Total Quality Management
Quản lý Chất lượng
tồn cục
25
UML
Unified Modeling Language
Ngơn ngữ Mơ hình hóa
26
WCC
Weighted classes per component
Lớp có trọng số cho
mỗi thành phần
27
WMC
Weigthed methods per class
Phương thức cú trng
s cho mi lp
Lương Thanh Bình
9
Luận văn tốt nghiệp CNTT 2005-2007
10
LI GII THIU
Hin nay, phn mềm đã trở thành một yếu tố không thể thiếu được trong đời
sống con người với rất nhiều lĩnh vực ứng dụng như ngân hàng, tài chính, truyền
thơng, khám phá, nghiên cứu khoa học, giải trí,…, nhu cầu về các biện pháp,
cơng cụ để đánh giá chính xác, liên tục và có thể dự đốn tiến trình phát triển
phần mềm và sản phẩm phần mềm ngày càng trở nên gắt gao.
Trong khi đó, giới chun mơn từ lâu đã thừa nhận rằng chất lượng của một
hệ thống phần mềm cần được đảm bảo ngay từ những pha đầu trong vòng đời
phần mềm. Với nhận thức như vậy, pha thiết kế phần mềm, là cầu nối giữa các
yêu cầu phi hình thức, mang tính chủ quan cao của người dùng và hoạt động
triển khai mang tính hình thức, đúng đắn; đây là giai đoạn tự nhiên nhất để đảm
bảo chất lượng một cách hiệu quả. Sản phẩm của pha thiết kế này là một kiến
trúc phần mềm mô tả các thành phần chức năng của hệ thống phần mềm và mối
quan hệ giữa các thành phần này.
Vì lẽ đó, chủ đề xác định chất lượng phần mềm dựa trên phân tích thiết kế
phần mềm ngày càng được quan tâm nhiều. Mặt khác, những lớp phổ biến nhất
trong các thành phần - mẫu thiết kế - là những lớp mô tả các giải pháp kỹ thuật
cho phép tái sử dụng và mở rộng được cho những vấn đề thiết kế phổ biến theo
một khuôn dạng hướng đối tượng chuẩn. Đây là một công cụ thiết kế mạnh nhờ
khả năng cho phép nhúng dưới dạng những biến thể của phần mềm hoặc kết hợp
với những thay đổi trong kiến trúc phần mềm. Kỹ nghệ sử dụng mẫu thiết kế
ngày càng hoàn thiện nên mẫu thiết kế cũng dần chiếm một vị trí quan trọng
trong chất lượng thiết kế. Ngoài ra, mẫu thiết kế cịn cho phép dự đốn chất
lượng của một hệ thống phần mềm từ kiến trúc của hệ thống đó mà cú cha cỏc
Lương Thanh Bình
10
Luận văn tốt nghiệp CNTT 2005-2007
11
mu thit k. Do vy, luận văn này tập trung vào vấn đề xác định chất lượng
kiến trúc phần mềm phổ biến dựa trên các mẫu thiết kế trong kiến trúc phần
mềm.
Bố cục luận văn gồm 4 chương như sau :
1. Chương 1 : Tổng quan về chất lượng phần mềm và độ đo chất
lượng phần mềm.
2. Chương 2 : Độ đo cho mẫu thiết kế
3. Chương 3 : Đánh giá kiến trúc phần mềm dựa trên mẫu thiết kế
4. Chương 4 : Thử nghiệm và đánh giá
5. Kết luận
Đề hoàn thành luận văn 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 vừa qua.
Tôi xin chân thành cảm ơn thầy giáo PGS. TS. Nguyễn Ngọc Bình, trường Đại
học Cơng nghệ-Đại học Quốc Gia Hà nội đã khuyến khích, động viên, góp ý và
hướng dẫn tơi rất tận tình trong suốt q trình thực hiện luận văn.
Và tơi cũng bày tỏ lịng biết ơn đối với tất cả các bạn bè, đồng nghiệp và
người thân đã động viên, hỗ trợ tôi để tơi có thể hồn thành luận văn này.
Tuy nhiên, trong quá trình làm luận văn, dù đã cố gắng thực hiện nhưng do kinh
nghiệm cịn ít, thời gian nghiên cứu hạn chế nên chắc chắn khơng tránh khỏi
thiếu sót, rất mong được sự giúp đỡ và góp ý của Quý thầy cơ, và đồng nghiệp
để luận văn này có thể phỏt trin mt cỏch hon thin hn.
Lương Thanh Bình
11
Luận văn tốt nghiệp CNTT 2005-2007
12
H ni ngy 8 thỏng 11 nm 2007.
Hc viờn
Lng Thanh Bỡnh
Lương Thanh Bình
12
Luận văn tốt nghiệp CNTT 2005-2007
13
CHNG 1: TNG QUAN V CHẤT LƯỢNG PHẦN MỀM VÀ
ĐỘ ĐO CHẤT LƯỢNG PHẦN MỀM
1.1.
Chất lượng phần mềm
1.1.1. Chất lượng-những quan điểm chung
Quan điểm phổ biến:
Có nhiều quan điểm về chất lượng nhưng đa số đều đồng ý rằng đây là một
đối tượng không thể nắm bắt được: ta có thể nói đến chất lượng, nhận xét về chất
lượng nhưng không thể đo được hoặc nói cách khác, khơng lượng hóa được chất
lượng. Với nhiều người, chất lượng là những đánh giá chung chung: chất lượng
tốt, chất lượng tồi hoặc chất lượng tạm được… những thuật ngữ hay được sử
dụng để nói về một đối tượng mập mờ khơng định nghĩa được hoặc khó định
nghĩa. Quan điểm này phản ánh thực tế là con người nhận thức và diễn đạt chất
lượng theo nhiều cách khi không thể quản lý, điều khiển hoặc định lượng được
chất lượng. Quan điểm này đối lập hẳn với quan điểm nhà nghề trong kỷ luật của
kỹ nghệ chất lượng rằng chất lượng có thể và cần được định nghĩa, đo đạc, giám
sát, quản lý và cải thiện.
Một quan điểm khá phổ biến khác coi chất lượng là sự xa xỉ và đẳng cấp.
Theo đó, những sản phẩm đắt tiền, xa hoa sẽ có chất lượng cao hơn những sản
phẩm xồng xĩnh. Và do đó, một chiếc Lexus sẽ là một chiếc xe chất lượng
nhưng Matiz thì khơng mà khơng cần xét tới các yếu tố về độ tin cậy cũng như
đối sánh các thuộc tính giữa chúng. Nói một cách đơn giản, chất lượng chỉ thuộc
về những sản phẩm đắt tiền với những chức năng kiểu cách còn những sản phẩm
rẻ tiền khó có thể coi là chất lượng.
Quan im chuyờn mụn:
Lương Thanh Bình
13
Luận văn tốt nghiệp CNTT 2005-2007
14
Nhng nhn thc sai xut phát từ những quan niệm như trên sẽ không giúp
cải thiện chất lượng trong các ngành cơng nghiệp. Vì vậy, trước tiên cần hiểu
đúng thế nào là chất lượng? Crosby (1979) [Cro79] định nghĩa chất lượng là “sự
tuân thủ các yêu cầu”, Juran và Gryna [JUG70] định nghĩa chất lượng là “sự phù
hợp với hoạt động sử dụng”. Có thể thấy hai định nghĩa này về cơ bản có tính
tương đồng và nhất quán với nhau. Hiện tại, nhiều tổ chức, công ty đã chấp nhận
và sử dụng cả hai định nghĩa:
• sự tuân thủ các yêu cầu: với các yêu cầu được phát biểu một cách tường
minh để không bị hiểu sai. Khi đó, tiến trình phát triển và sản xuất thường
xuyên thực hiện các phép đo nhằm xác định độ tuân thủ theo các yêu cầu.
Trong quá trình này, những chi tiết không tuân thủ bị coi là khiếm khuyếtsụt giảm chất lượng. Như vậy, nếu một chiếc Lexus đảm bảo được tất cả
các yêu cầu cho một chiếc Lexus, đó sẽ là một chiếc ơ tơ chất lượng. Và,
nếu một chiếc Matiz đảm bảo được tất cả các yêu cầu cho một chiếc
Matiz, đó cũng là một chiếc ô tô chất lượng. Hai loại ô tô này khác nhau
về chủng loại, hiệu năng, và tính kinh tế nhưng do được đo trên các tiêu
chuẩn tương ứng nên cùng là những chiếc ơ tơ chất lượng.
• sự phù hợp với hoạt động sử dụng: cách định nghĩa này xét tới yêu cầu và
sự kỳ vọng từ phía khách hàng có nghĩa là các sản phẩm hoặc các dịch vụ
liệu có phù hợp với sự đa dạng trong nhu cầu sử dụng của khách hàng.
Theo Juran, hai thông số quan trọng nhất của sự phù hợp với hoạt động sử
dụng là chất lượng thiết kế và chất lượng tuân thủ.
Quan điểm chất lượng từ phía khách hàng
Xét từ phía khách hàng, chất lượng là giá trị thu nhận được từ sản phẩm mua
về, dựa trên rất nhiều yếu tố như giá cả, hiệu năng, tính tin cậy, độ thỏa món.
Lương Thanh Bình
14
Luận văn tốt nghiệp CNTT 2005-2007
15
Trong ú, mc tha mãn sau khi mua sản phẩm là tiêu chí xét duyệt chất
lượng quan trọng nhất để biết sản phẩm tuân thủ các yêu cầu và phù hợp với mục
đích sử dụng. Với hai nhận thức về chất lượng như trên nên trong thực tế, định
nghĩa chất lượng thường có hai cung bậc:
• định nghĩa chất lượng nội tại thường gắn với tỉ suất sai sót và độ tin cậy.
Định nghĩa hẹp này thường được gọi là “q nhỏ”-“small q” ( q: qualitychất lượng).
• định nghĩa rộng hơn: gồm chất lượng sản phẩm, chất lượng tiến trình và
sự thỏa mãn của khách hàng, được gọi là “Q lớn”-“big-Q”.
Hai mức định nghĩa trên hiện được dùng trong rất nhiều ngành công nghiệp.
Trong phạm vi luận văn này, tác giả chỉ xét định nghĩa chất lượng theo mức rộng
“big-Q”.
Từ hai mức chất lượng, đã hình thành một chu trình lặp khép kín trong sản
xuất phần mềm: nhu cầu và mong muốn của khách hàng yêu cầu và đặc tả
sản phẩm được thiết kế, phát triển theo yêu cầu với sự tập trung liên tục vào cải
thiện quy trình chất lượng sản phẩm hồn hảo, cộng thêm q trình phân phối
và dịch vụ tốt sự thỏa mãn tuyệt đối của khách hàng. Tuy nhiên, q trình
này khơng phải lúc nào cũng đúng đặc biệt là trước thời điểm những năm cuối
của thập kỷ 1980, thời điểm khởi thủy cho khái niệm chất lượng theo quan điểm
hiện đại.
1.1.2. Định nghĩa
Mỗi nhà phát triển đều có một ý tưởng riêng về chất lượng nên bước đầu tiên
trong một dự án phát triển phần mềm là nêu rõ mối quan hệ giữa yêu cầu, đặc
tính phần mềm và chất lượng phần mềm để xác nh cỏc ch tiờu cht lng ca
Lương Thanh Bình
15
Luận văn tốt nghiệp CNTT 2005-2007
16
phn mm. Hỡnh 1.1 minh họa một sản phẩm phần mềm đáp ứng những yêu cầu
xác định để có được những đặc tính phù hợp.
sản phẩm phần mềm
Q
Q
phải
đáp ứng
có
liên quan tới
u cầu
(giúp đáp ứng)
đặc tính
Hình 1.1: Quan hệ giữa yêu cầu và các đặc tính chất lượng
Trong phần mềm, nghĩa hẹp nhất của chất lượng sản phẩm thường được hiểu
là sản phẩm “khơng có lỗi”, là ý nghĩa cơ bản nhất của việc tuân thủ các yêu cầu.
Định nghĩa chất lượng phần mềm thường dựa trên một số đặc tính chất lượng.
nên các đặc tính này thường được tính đến khi lập kế hoạch và thiết kế phần
mềm tuy không phải lúc nào chúng cũng tương hợp với nhau. Ví dụ, càng nhiều
chức năng (độ phức tạp càng lớn), phần mềm càng khó bảo trì. Tùy thuộc vào
loại phần mềm và khách hàng mà ta dành sự quan tâm khác nhau cho các đặc
tính chất lượng phân biệt.
Nhằm cải thiện chất lượng trong tiến trình phát triển, người ta đã đưa ra
những mơ hình tiến trình phát triển phần mềm với những định hướng, giải pháp
cụ thể cùng những cơng cụ và kỹ thuật thích hợp. Các đặc tính và các tham số
chất lượng của tiến trình phát triển theo pha cũng như sản phẩm đầu ra của từng
pha sẽ được đo đạc, giám sát để đảm bảo tiến trình phát triển và các sản phm
Lương Thanh Bình
16
Luận văn tốt nghiệp CNTT 2005-2007
17
ca tng pha vn nm trong tầm điều khiển và đang hướng tới những mục tiêu
chất lượng. Tuy nhiên, luận văn này không tập trung nghiên cứu độ đo chất
lượng trên cơ sở quy trình mà sẽ hướng đến độ đo chất lượng cho sản phẩm phần
mềm mà cụ thể là sản phẩm của pha thiết kế phần mềm.
Từ các khía cạnh liên quan trình bày ở trên, ta có định nghĩa về chất lượng
phần mềm:
“Chất lượng phần mềm được coi là sự tuân thủ những yêu cầu về mặt chức
năng và hiệu năng đã được xác định một cách rõ ràng, những chuẩn phát triển
được tài liệu hóa và những đặc tính ngầm định.” Trong đó:
• Các u cầu phần mềm là nền tảng để đo đạc chất lượng.
• Các chuẩn định nghĩa các tiêu chí phát triển, là dẫn hướng cho cách xây
dựng phần mềm.
• Các yêu cầu ngầm định giúp phần mềm đạt được chất lượng hoàn hảo.
Tồn tại hai mức chất lượng phần mềm:
• Chất lượng phần mềm nội tại-Internal software quality: là phần ẩn của
tảng băng, ví dụ cấu trúc chương trình, kiểu viết mã nguồn, khả năng bảo
trì, sự thông thạo chuyên môn... Phần chất lượng này chỉ dành cho phía
nhà phát triển. Khi chất lượng nội tại khơng đạt yêu cầu sẽ tiêu tốn nhiều
thời gian phát triển, gây ra các lỗi dây chuyền và mất nhiều thời gian kiểm
thử. Xét từ quan điểm thương trường, chất lượng nội tại không tốt sẽ làm
suy giảm nghiêm trọng tới uy tín và khả năng cạnh tranh của cơng ty.
• Chất lượng phần mềm bên ngoài-External software quality: là phần chất
lượng mà khách hàng thấy được và có thể kiểm thử theo những phương
pháp truyền thống. Khi chất lượng phần mm bờn ngoi khụng t yờu cu
Lương Thanh Bình
17
Luận văn tốt nghiệp CNTT 2005-2007
18
cú th xy ra nhng hiện tượng như: sập hệ thống, không xử lý hoặc xử lý
sai dữ liệu/lệnh đưa vào, sai lệch dữ liệu, tốc độ chậm…
Chất lượng bên ngoài thường là kết quả của chất lượng nội tại. Chất lượng
nội tại nghèo nàn sẽ dẫn đến chi phí bảo trì cao. Do đó, để nâng cao được chất
lượng phần mềm cần nâng cao chất lượng nội tại.
1.1.3. Đánh giá kiến trúc phần mềm
Một nguyên lý đã được chấp nhận lâu nay trong công nghệ phần mềm là chất
lượng của một hệ thống phần mềm cần được đảm bảo ngay từ những pha đầu
trong vòng đời phần mềm. Các phương pháp bảo đảm chất lượng sẽ đặc biệt hiệu
quả khi nắm bắt được các u cầu của hệ thống và khơng cịn nhiều hiệu quả khi
hệ thống đã đưa vào vận hành.
Nhưng điều bất lợi là ta không thể áp dụng các phương pháp bảo đảm chất
lượng ngay trong những pha phát triển đầu tiên nếu chỉ dựa vào những tài liệu
ghi chép thông thường. Trong khi đó, những phương pháp có mức tự động hóa
cao (như kiểm thử) chỉ được áp dụng về sau khi mà chi phí chỉnh sửa sẽ tương
đối tốn kém.
Pha thiết kế phần mềm được coi là cầu nối giữa các u cầu phi hình thức,
mang tính chủ quan cao của người dùng và hoạt động triển khai mang tính hình
thức, đúng đắn; đây là giai đoạn tự nhiên nhất để đảm bảo chất lượng một cách
hiệu quả. Mặt khác, thiết kế phần mềm là một trong những pha của hoạt động
phát triển phần mềm mà nhà thiết kế vẫn làm việc ở một mức trừu tượng cao mà
chưa đi sâu vào chi tiết. Sản phẩm của pha thiết kế này là một kiến trúc phần
mềm mô tả các thành phần chức năng của hệ thống phần mềm và mối quan hệ
giữa các thành phần này. Trong những năm gần đây, kiến trúc phần mềm ngày
càng được coi trọng, trở thành yếu tố nền móng trong chất lượng phần mm.
Lương Thanh Bình
18
Luận văn tốt nghiệp CNTT 2005-2007
19
Vỡ l ú, ch xác định chất lượng phần mềm dựa trên phân tích thiết kế
phần mềm ngày càng được quan tâm nhiều. Đặc biệt khi mà cộng đồng hướng
đối tượng đã xử lý được những bài toán thường xuyên xuất hiện bằng cách tập
hợp và chuẩn hóa những thành phần hay được sử dụng trong những bài tốn này.
Khi đó, những lớp phổ biến nhất trong các thành phần được gọi là mẫu thiết kế
[LPR98], các lớp đó mơ tả các giải pháp kỹ thuật cho phép tái sử dụng và mở
rộng được cho những vấn đề thiết kế phổ biến theo một khuôn dạng hướng đối
tượng chuẩn. Ý tưởng chung của mẫu thiết kế là áp dụng một giải pháp thiết kế
dưới một hình thức tường minh để áp dụng được vào một hồn cảnh cụ thể mà
vẫn cho phép phân tích được ưu điểm và nhược điểm của giải pháp. Có thể tìm
thấy các mẫu trong các hệ thống đã có hoặc có thể tạo mới mẫu từ đầu. Yếu tố
khiến mẫu thiết kế trở thành một công cụ thiết kế mạnh là nhờ khả năng của mẫu
thiết kế cho phép nhúng dưới dạng những biến thể của phần mềm hoặc kết hợp
với những thay đổi trong kiến trúc phần mềm. Kỹ nghệ sử dụng mẫu thiết kế
ngày càng hoàn thiện nên mẫu thiết kế cũng dần chiếm một vị trí quan trọng
trong chất lượng thiết kế. Hơn nữa, với những ưu điểm cũng như nhược điểm đã
xác định được, mẫu thiết kế cịn cho phép dự đốn chất lượng của một hệ thống
phần mềm từ kiến trúc của hệ thống đó mà có chứa các mẫu thiết kế. Do vậy,
một hướng xác định chất lượng kiến trúc phần mềm phổ biến hiện nay là dựa
trên các mẫu thiết kế trong kiến trúc phần mềm. Ngồi ra, các mẫu tìm được
cịn cho phép dự đoán chất lượng của các hệ thống thực tế phát triển về sau.
1.1.4. Các chuẩn chất lượng phần mềm
• ISO 9001: Các hệ thống chất lượng-Mơ hình Thiết kế và Đảm bảo Chất
lượng -Quality Systems-Model for Quality Assurance and Design
Lương Thanh Bình
19
Luận văn tốt nghiệp CNTT 2005-2007
20
ã ISO 9004-2: Cỏc thnh phần Hệ thống Chất lượng và Quản lý Chất lượngQuality Management and Quality System Elements
• ISO 9000-3: Các dẫn hướng để ứng dụng ISO 9001 cho Phát triển, Cung
cấp và Bảo trì Phần mềm
Trong các chuẩn trên, đặc biệt phải kể đến ISO 9126, tiêu chuẩn được giám
sát bởi dự án SQuaRE, ISO 25000:2005 dựa trên các khái niệm chung tương
đương. Tiêu chuẩn này được chia thành 4 phần: mô hình chất lượng, các độ đo
ngồi, các độ đo trong, các độ đo chất lượng sử dụng.
Mẫu chất lượng được thiết lập ở phần đầu của tiêu chuẩn, mơ hình này được
đặt tên là ISO 9126-1, phân loại chất lượng phần mềm theo một tập các tính
năng và tính năng con như sau:
• Tính chức năng-functionality
• Tính tin cậy-reliability
• Tính tiện dùng-usability
• Tính hiệu quả-efficiency
• Tính dễ bảo trì-maintainability
• Tính khả chuyển-portability
Tính chức năng
Một tập các chức năng liên quan đến sự tồn tại của các tính năng với những
thuộc tính cụ thể. Những tính năng này phải tuân thủ các yêu cầu ngầm định
hoặc yêu cầu tường minh, gồm các tính năng con:
Phù hợp
Đúng đắn
Liên kết các yếu tố con người, dữ liệu và hệ thống
Tuõn th cỏc yờu cu
Lương Thanh Bình
20
Luận văn tốt nghiệp CNTT 2005-2007
21
Tớnh bo mt
Tớnh tin cậy
Một tập các tính năng liên quan đến khả năng duy trì hoạt động của phần mềm
trong những điều kiện đã định trong một khoảng thời gian nhất định, gồm các
tính năng con:
Xử lý tin cậy
Khả năng khơi phục dữ liệu
Tính chịu lỗi
Tính tiện dùng
Một tập các tính năng liên quan đến những nỗ lực cần thiết để sử dụng phần
mềm và những đánh giá từ phía người dùng theo kiểu ngầm định hoặc tường
minh, gồm các tính năng con:
Dễ học thuộc
Dễ hiểu
Dễ thành thạo
Dễ sử dụng
Tính hiệu quả
Những tính năng liên quan đến mối quan hệ giữa khả năng thực hiện của phần
mềm và khối lượng tài nguyên cần sử dụng trong những điều kiện nhất định,
gồm các tính năng con:
Quản lý thời gian
Quản lý nguồn tài nguyên
Tính dễ bảo trì
Những tính năng liên quan đến hoạt động cập nhật, gm cỏc tớnh nng con:
Chy n nh
Lương Thanh Bình
21
Luận văn tốt nghiệp CNTT 2005-2007
22
Cú kh nng phõn tích dữ liệu
Có khả năng thay đổi phù hợp
Có khả năng kiểm tra
Tính khả chuyển
Những tính năng liên quan đến khả năng chuyển rời phần mềm từ nơi này đến
nơi khác, gồm các tính năng con:
Khả năng cài đặt
Khả năng thay thế, cập nhật và nâng cấp
Khả năng thích hợp với nhiều cấu hình máy tính.
Tiêu chuẩn này hiện được nhiều cơ quan, tổ chức chuyên làm phần mềm công
nhận và áp dụng.
1.2.
Tại sao cần độ đo phần mềm
Cuối thế kỷ vật lý, Lord Kelvin (1824-1904) đã xây dựng một lý thuyết về đo
đạc: “Khi ta có thể đo đối tượng đang xét và biểu diễn ở dạng số, ta đã thu được
một số tri thức về đối tượng đó, nhưng khi ta khơng thể đo được, khi không thể
biểu diễn đối tượng ở dạng số, tri thức của ta về đối tượng sẽ tương đối sơ sài và
khơng thể thỏa mãn được: đó chỉ là khởi điểm của tri thức và chắc chắn chưa có
tiến bộ về mặt tri thức trong lĩnh vực khoa học.”
Với thực tế là phần mềm đã trở thành một yếu tố không thể thiếu được trong
đời sống con người với rất nhiều lĩnh vực ứng dụng như ngân hàng, tài chính,
truyền thơng, khám phá, nghiên cứu khoa học, giải trí,…, nhu cầu về các biện
pháp, cơng cụ để điều khiển chính xác, liên tục và có thể dự đốn tiến trình phát
triển phần mềm và sản phẩm phần mềm ngày càng trở nên gắt gao. Cách đây 40
năm người ta đã đề xuất độ đo cho lĩnh vực công ngh phn mm khi m chi phớ
Lương Thanh Bình
22
Luận văn tốt nghiệp CNTT 2005-2007
23
phỏt trin v bo trỡ phần mềm không ngừng tăng lên đã thúc đẩy việc sử dụng
các phép đo nhằm hỗ trợ hoạt động phát triển phần mềm và công tác quản lý.
Qua nhiều thời kỳ phát triển, độ đo phần mềm hiện nay được dùng khá phổ
biến, từ việc tạo ra những thông số đặc trưng cho các thuộc tính mã nguồn
(những độ đo phần mềm cổ điển) tới các mơ hình dự đốn yêu cầu tài nguyên
phần mềm và chất lượng phần mềm. Ngồi ra, cịn có các đại lượng định lượng
được, phục vụ cho mục đích điều khiển chất lượng và giám sát lỗi trong quá
trình phát triển và kiểm thử.
Ngày nay, độ đo phần mềm đang là một lĩnh vực quan tâm hàng đầu trong
công nghệ phần mềm do thực trạng xây dựng phần mềm.
Một khảo sát năm 2000 của Bộ Quốc Phịng Mỹ cho thấy:
• Hầu hết các hệ thống phức tạp mà Bộ Quốc Phòng Mỹ phải mua là các
phần mềm chun dụng.
• Phần mềm là thành phần có nguy cơ rủi ro cao nhất trong các chương trình
của Bộ Quốc Phịng Mỹ
• Điều tra trên 800 nhà lập trình:
- 52,7% số dự án được hồn thành nhưng có lỗi tiềm ẩn và trễ hạn
- Chi phí vượt định mức trung bình là 189%
- 31,1% dự án phần mềm đã phải hủy
- Các dự án khó (52,7%) đã được phát hành chỉ với 61% chức năng được
đặc tả ban đầu
Như vậy, có thể thấy khi khơng quản lý được dự án do khơng đo được các
đặc tính của sản phẩm ngay từ những pha đầu của chu trình xây dựng phần mềm,
nhà phát triển sẽ không biết phần mềm làm ra có đáp ứng được hoặc đáp ứng
đúng các yờu cu hay khụng.
Lương Thanh Bình
23
Luận văn tốt nghiệp CNTT 2005-2007
24
Mc ớch ca cỏc phộp đo là trả lời các câu hỏi sau:
1) Có thể dự đoán khả năng xảy ra lỗi của một hệ thống bằng các độ đo phần
mềm trong pha thiết kế khơng?
2) Có thể thêm các đặc tính định lượng khi thiết kế phần mềm để dự đốn
khả năng bảo trì của một hệ thống phần mềm?
3) Liệu có tồn tại các đặc tính then chốt trong mã nguồn mà định lượng được
để dự đốn mức độ khó khi kiểm thử mã nguồn đó và số lỗi cịn lại sau khi
đã thực hiện một số kiểm thử?
4) Có thể thêm các đặc tính định lượng được vào thiết kế phần mềm giúp dự
đoán nỗ lực cần thiết để xây dựng phần mềm theo thiết kế đã mơ tả?
5) Có tồn tại những tính năng giúp dự đốn kích thước dự án từ pha đặc tả?
6) Thuộc tính nào trong các độ đo phần mềm sẽ đảm bảo chất lượng thiết kế?
7) Đâu là những phép đo phần mềm phù hợp làm cơ sở cho những thuộc tính
phần mềm của các thơng số trong chuẩn ISO 9126?
Trên cơ sở đó, các độ đo phần mềm được dùng để đo các thuộc tính xác định
của một sản phẩm phần mềm hoặc tiến trình phát triển phần mềm. Ta sử dụng
các phép đo phần mềm để thu được:
• Tạo cơ sở để đánh giá phần mềm
• Theo vết tiến trình dự án
• Xác định (một cách tương đối) độ phức tạp cho dự án phát triển phần mềm
• Xác định mức độ chất lượng hiện tại
• Phân tích hoặc xác định lỗi
• Thơng qua thực nghiệm mà chứng tỏ được những kỹ thuật tối u nht
Lương Thanh Bình
24
Luận văn tốt nghiệp CNTT 2005-2007
1.3.
25
o phn mm
1.3.1. nh nghĩa độ đo phần mềm
Tất cả các nhà lập trình ít nhiều đều có sử dụng độ đo phần mềm. Tuy nhiên,
khi được hỏi độ đo phần mềm là gì, hầu đều chỉ giới hạn ở đo kích thước phần
mềm như số dòng mã nguồn hoặc số function-point. Trong thực tế, độ đo phần
mềm còn bao hàm nhiều yếu tố khác mà khơng chỉ là kích thước chương trình.
Độ đo phần mềm là những đại lượng cung cấp thông tin hỗ trợ quá trình ra
các quyết định quản lý mang tính định lượng trong vịng đời phần mềm. Tồn tại
nhiều định nghĩa về độ đo phần mềm. Một trong những định nghĩa hay là định
nghĩa của Goodman: “Việc ứng dụng liên tục các kỹ thuật dựa trên độ đo cho
tiến trình phát triển phần mềm và các sản phẩm để cung cấp các thơng tin quản
lý có ý nghĩa và theo thời gian, cùng với việc sử dụng những kỹ thuật này để cải
thiện tiến trình và các sản phẩm” [Goo93]. Chúng ta sẽ sử dụng định nghĩa độ
đo này trong luận văn. Hình 1.2 minh họa định nghĩa trên, có xét các dịch vụ liên
quan như cài đặt và phản hồi yêu cầu của khách hàng.
Thế nào là
độ đo phần mềm?
Các kỹ thuật dựa trên
phép đo
áp dụng
cho
Tiến trình,
Sản phẩm,
Dịch vụ
để cung cấp
để cải thiện
Thơng tin
Kỹ nghệ và
Quản lý
Hình 1.2: Th no l o phn mm
Lương Thanh Bình
25
