Nghiên cứu và phát triển một cơ sở tri thức hỗ trợ nâng cao chất lượng hoạt động sản xuất phần mềm

ĐẠI HỌC QUỐC GIA TP. HCM
TRƢỜNG ĐẠI HỌC BÁCH KHOA
--------------------------

HỒ XUÂN CẨM TRANG

NGHIÊN CỨU VÀ PHÁT TRIỂN MỘT CƠ SỞ TRI THỨC
HỖ TRỢ NÂNG CAO CHẤT LƢỢNG HOẠT ĐỘNG SẢN
XUẤT PHẦN MỀM

Chun ngành: Hệ thống thơng tin quản lí
Mã số chuyên ngành: 60 34 48

LUẬN VĂN THẠC SĨ

TP. HỒ CHÍ MINH, tháng 06 năm 2013


CƠNG TRÌNH ĐƢỢC HỒN THÀNH TẠI
TRƢỜNG ĐẠI HỌC BÁCH KHOA –ĐHQG –HCM
Cán bộ hƣớng dẫn khoa học : TS.Nguyễn Chánh Thành…………………………...
Cán bộ chấm nhận xét 1 : ...........................................................................
Cán bộ chấm nhận xét 2 : ...........................................................................

Luận văn thạc sĩ đƣợc bảo vệ tại Trƣờng Đại học Bách Khoa, ĐHQG Tp. HCM
ngày . . . . . tháng . . . . năm . . . . .
Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm:
1. ..............................................................
2. ..............................................................
3. ..............................................................
4. ..............................................................

5. ..............................................................
Xác nhận của Chủ tịch Hội đồng đánh giá LV và Trƣởng Khoa quản lý chuyên
ngành sau khi luận văn đãđƣợc sửa chữa (nếu có).
CHỦ TỊCH HỘI ĐỒNG

TRƢỞNG KHOA


ĐẠI HỌC QUỐC GIA TP.HCM
TRƢỜNG ĐẠI HỌC BÁCH
KHOA

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT
NAM Độc lập - Tự do - Hạnh phúc

NHIỆM VỤ LUẬN VĂN THẠC SĨ
Họ tên học viên: Hồ Xuân Cẩm Trang ...................................... MSHV:11320984 ............
Ngày, tháng, năm sinh: 14/05/85 ............................................... Nơi sinh: Kon Tum .........
Chuyên ngành: Quản Lý Hệ Thống Thông Tin......................... Mã số : 60 34 48 ...........
I. TÊN ĐỀ TÀI: Nghiên cứu và phát triển một cơ sở tri thức hỗ trợ hoạt động sản xuất
phần mềm
II. NHIỆM VỤ VÀ NỘI DUNG
 Hình thành một cơ sở tri thức về các lỗi phát triển trong quá trình sản xuất
phần mềm bao gồm các thơng tin về dạng lỗi, nguyên nhân lỗi và cách phòng
tránh.
 Xây dựng một cơ chế hỗ trợ ngƣời dùng truy cập cơ sở tri thức
 Đánh giá mức độ hỗ trợ của cơ sở tri thức đối với việc nâng cao chất lƣợng của
hoạt động sản xuất phần mềm
III. NGÀY GIAO NHIỆM VỤ : 21/01/2013
IV. NGÀY HOÀN THÀNH NHIỆM VỤ: 21/06/2013

V. CÁN BỘ HƢỚNG DẪN : TS. Nguyễn Chánh Thành

Tp. HCM, ngày . . . . tháng .. . . năm 20....
CÁN BỘ HƢỚNG DẪN

CHỦ NHIỆM BỘ MÔN ĐÀO TẠO

TRƢỞNG KHOA


i

LỜI CÁM ƠN
Trƣớc tiên, tôi xin đƣợc gửi lời cảm ơn đến quý Thầy Cô của trƣờng Đại học Bách khoa
TP. HCM đã trang bị cho tôi những kiến thức quý báu trong thời gian tôi học cao học
ngành Hệ thống Thông tin Quản lý.
Xin đặc biệt cảm ơn TS. Nguyễn Chánh Thành, ngƣời hƣớng dẫn khoa học của đề tài.
Thầy đã rất tận tình hƣớng dẫn và định hƣớng cho tơi trong việc nghiên cứu và hồn
thành đề tài này.
Cuối cùng, tôi xin gửi lời cảm ơn đến tất cả những ngƣời bạn, những ngƣời đồng
nghiệpđã tận tình hỗ trợ và giúp đỡ, góp ý cho tơi trong suốt thời gian học tập và nguyên
cứu đề tài.
Hồ Xuân Cẩm Trang


ii

TĨM TẮT LUẬN VĂN THẠC SĨ
Luận văn sẽ trình bày việc nghiên cứu và phát triển một cơ sở tri thức hỗ trợ nâng cao
chất lƣợng sản xuất phần mềm. Thơng qua kết quả phân tích nhu cầu của các đối tƣợng là

chính các chuyên gia hoạt động trong lĩnh vực này, luận vănsẽ phát triển một cơ sở tri
thức về các lỗi phát sinh trong quá trình sản xuất phần mềm. Luận văn sẽ tập trung xây
dựng một ontology về lỗi phần mềm và hiện thực nó bằng cách thu thập dữ liệu về lỗi
phần mềm từ 5 dự án khác nhau có qui mơ khá lớn ở một số cơng ty phần mềm, sau đó
phân loại dựa trên phƣơng pháp ODC, từ đó tìm ra ngun nhân và đề nghị một số biện
pháp phịng tránh. Ngồi ra luận văn cũng xâydựng đƣợc một cơ chế hỗ trợ ngƣời dùng
truy cập và sử dụng cơ sở tri thức vàtrình bày một số cácphƣơng pháp thực nghiệm nhằm
đánh giá mức độ đáp ứng của cơ sở tri thức trong việc hỗ trợ các lập trình viên nói riêng
cũng nhƣ trong việc giảm chi phí và nâng cao chất lƣợng phần mềm nói chung.
Từ khố: Defect, Defect Analysis, Root Cause Analysis, Prevent Action, ODC


iii
ABSTRACT
Based on the fact that the cost of finding and correcting defect represents one of the most
expensive software development activites, this study will present a research and
implementation of a knowledge base about defect in order to improve the quality of
software development. This study will focus on developing a defect ontology, then
creates a defect knowledge base by finding and analysis the defect data that occurred in
the software development process for five big projects and aims at classifying various
defect using Orthogonal Defect Classification (ODC), finding root cause of defects and
suggest some prevention ideas. The study also built a web application for the defect
knowledge base can be accessed and used. Then by conducting some experiments, it also
showcase on how the knowledge base helps the developers in their work in particular or
to improve the software development quality in general.
Keywords: Defect, Defect Analysis, Root Cause Analysis, Prevent Action, ODC


iv

LỜI CAM ĐOAN

Tơi xin cam đoan rằng tồn bộ những nội dung và số liệu trong luận văn này do tôi tự
nghiên cứu, khảo sát và thực hiện. Những dữ liệu đƣợc thu thập và xử lí một cách khách
quan và trung thực.
Hồ Xuân Cẩm Trang


v

MỤC LỤC
LỜI CÁM ƠN ..................................................................................................................... i
TÓM TẮT LUẬN VĂN THẠC SĨ ................................................................................... ii
LỜI CAM ĐOAN.............................................................................................................. iv
MỤC LỤC .......................................................................................................................... v
DANH MỤC HÌNH ẢNH .............................................................................................. viii
DANH MỤC BẢNG ......................................................................................................... ix
DANH MỤC CÁC THUẬT NGỮ VÀ TỪ VIẾT TẮT .................................................. x
CHƢƠNG 1

TỔNG QUAN..................................................................................... 1

1.1

Giới thiệu ............................................................................................................... 1

1.2

Mục tiêu ................................................................................................................. 3

1.3

Đối tƣợng nghiên cứu ............................................................................................ 3

1.4

Phƣơng pháp nghiên cứu ....................................................................................... 4

1.5

Các cơng trình nghiên cứu liên quan ..................................................................... 4

CHƢƠNG 2
2.1

CƠ SỞ LÝ THUYẾT ........................................................................ 9

Cơ sở lí thuyết về lỗi .............................................................................................. 9

2.1.1

Lỗi ................................................................................................................... 9

2.1.2

Mơ hình phân loại lỗi ODC ............................................................................. 9

2.1.3

Kiểu lỗi (Defect Type): .................................................................................. 11

2.1.4

Kích hoạt lỗi (Defect Trigger)....................................................................... 13

2.1.5

Tác động của lỗi (Defect Impact) .................................................................. 13

2.2

Tri thức và cơ sở tri thức ...................................................................................... 14

2.2.1

Tri thức .......................................................................................................... 14

2.2.2

Đặc tính của tri thức: ..................................................................................... 17


vi
2.2.3

Quản lí tri thức .............................................................................................. 17

2.2.4

Quản lí tri thức trong lĩnh vực sản xuất phần mềm....................................... 18

2.2.5

Cơ sở tri thức ................................................................................................. 19

2.3

Giới thiệu về ontology ......................................................................................... 21

2.3.1

Khái niệm ...................................................................................................... 21

2.3.2

Tại sao phải xây dựng Ontology? ................................................................. 22

2.3.3

Phƣơng pháp xây dựng Ontology ................................................................. 24

2.3.4

OWL – Web Ontology Language ................................................................. 26

CHƢƠNG 3
3.1

PHƢƠNG PHÁP NGHIÊN CỨU .................................................. 28

Các bƣớc thực hiện .............................................................................................. 28

3.1.1

Phân tích nhu cầu .......................................................................................... 28

3.1.2

Thu thập dữ liệu ............................................................................................ 30

3.1.3

Phân tích dữ liệu ............................................................................................ 31

3.1.4

Xây dựng Ontology ....................................................................................... 32

3.1.5

Xây dựng cơ chế hỗ trợ truy cập cơ sở tri thức ............................................. 32

3.2

Qui tắc 80/20 ........................................................................................................ 33

CHƢƠNG 4
4.1

XÂY DỰNG CƠ SỞ TRI THỨC ................................................... 35

Kiến trúc của cơ sở tri thức .................................................................................. 35

4.1.1

Ontology ........................................................................................................ 35

4.1.2

Từ Ontology đến cơ sở tri thức ..................................................................... 41

4.2

4.1.2.1

Lƣợc đồ cơ sở dữ liệu ........................................................................ 41

4.1.2.2

Tạo nên các thực thể của Ontology ................................................... 42

Ứng dụng (demo) ................................................................................................. 43

CHƢƠNG 5
5.1

THỰC NGHIỆM VÀ ĐÁNH GIÁ ................................................. 45

Kết quả thực nghiệm ............................................................................................ 45

vii
5.1.1

Thu thập dữ liệu ............................................................................................ 45

5.1.2

Phân tích và đánh giá .................................................................................... 47

5.1.3

Tổng quát một số nội dung của cơ sở tri thức ............................................... 56

5.2

Hậu kiểm .............................................................................................................. 63

5.2.1

Đánh giá mức độ đáp ứng và độ tin cậy của cơ sở tri thức ........................... 63

5.2.2

Bƣớc cải tiến ................................................................................................. 68

CHƢƠNG 6

KẾT LUẬN VÀ HƢỚNG PHÁT TRIỂN ..................................... 69

DANH MỤC CÁC TÀI LIỆU THAM KHẢO ............................................................. 71


viii

DANH MỤC HÌNH ẢNH
Hình 2-1: Mơ hình mơ tả sự phân bổ của các lỗi qua các giai đoạn phát triển của dự án [7]
........................................................................................................................................... 10
Hình 2-2 : Chu kì hình thành của tri thức .......................................................................... 15
Hình 2-3: Mơ hình dữ liệu, thơng tin và tri thức ............................................................... 16
Hình 2-4 Sơ đồ thể hiện mục đích của việc xây dựng ontology ....................................... 24
Hình 3-1: Sơ đồ Pareto biểu diễn lí do đến trễ của nhân viên văn phịng ......................... 34
Hình 4-1 Mơ tả ontology về lỗi phần mềm ....................................................................... 36
Hình 4-2 Defect Type Ontology ....................................................................................... 37
Hình 4-3 Root Cause Ontology ........................................................................................ 38
Hình 4-4 Defect Trigger Ontology ................................................................................... 39
Hình 4-5: Defect Impact Ontology ................................................................................... 41
Hình 4-6 Lƣợc đồ cơ sở dữ liệu......................................................................................... 42
Hình 4-7 Ứng dụng hỗ trợ tìm kiếm lỗi............................................................................. 43
Hình 4-8 Ứng dụng hỗ trợ truy cập thơng tin chi tiết về lỗi .............................................. 44
Hình 5-1: Sơ đồ Paterio về phân loại lỗi qua các giai đoạn phát triển của dự án ............. 51
Hình 5-2: Sơ đồ Pareto về phân loại lỗi theo Defect Type ............................................... 53
Hình 5-3: Sơ đồ Paterio về phân loại lỗi theo Defect Impact ........................................... 55
Hình 5-4: Lƣợc đồ nguyên nhân hệ quả của lỗi phần mềm .............................................. 57
Hình 5-5: Tỉ lệ đánh giá của lập trình viên cho 33/100 lỗi tìm đƣợc từ cơng cụ truy cập 65
Hình 5-6: Đánh giá chất lƣợng của thơng tin trên 200 mẫu thử ........................................ 66
Hình 5-7: Đánh giá mức độ đáp ứng đối với nhu cầu sử dụng thực tế ............................. 67


ix

DANH MỤC BẢNG
Bảng 5-1: Thông tin về lỗi thu thập đƣợc qua các dự án .................................................. 45
Bảng 5-2: Thống kê các mối quan hệ ngữ nghĩa của lớp Defect ...................................... 47
Bảng 5-3: Phân loại lỗi phần mềm qua các giai đoạn của 5 dự án đƣa vào nghiên cứu ... 50
Bảng 5-4: Phân bố lỗi theo Defect Type ........................................................................... 52
Bảng 5-5: Phân bố lỗi theo Defect Impact ........................................................................ 54
Bảng 5-6: Phân bổ lỗi theo Defect Trigger ....................................................................... 55
Bảng 5-7: Nguyên nhân và cách khắc phục lỗi phần mềm ............................................... 58
Bảng 5-8: Hậu kiểm sử dụng công cụ truy cập cơ sở tri thức ........................................... 64


x

DANH MỤC CÁC THUẬT NGỮ VÀ TỪ VIẾT TẮT
Thuật ngữ (viết tắt)

Giải thích

Orthogonal Defect
ODC là phƣơng pháp do IBM phát triển vào những năm
Classification (ODC) 1990s bởi Ram Chillarege để phân loại và phân tích lỗi
trong tất cả các giai đoạn phát triển của một dự án phần
mềm.
World Wide Web
Consortium ( W3C)

Tổ chức tiêu chuẩn quốc tế về web trên internet.

1000 lines of code

(KLOC)

Số lƣợng dịng code tính theo đơn vị 1000 dòng.

Graphical User
Interface (GUI)

Giao diện giao tiếp với ngƣời dùng máy tính.

HyperText Markup
Language (HTML)

Một ngơn ngữ đánh dấu đƣợc thiết kế ra để tạo nên các trang
web với các mẩu thơng tin đƣợc trình bày trên World Wide
Web.

eXtensible Markup
Language (XML)

Ngơn ngữ đánh dấu với mục đích chung do W3C đề nghị, để
tạo ra các ngôn ngữ đánh dấu khác và có khả năng mơ tả
nhiều loại dữ liệu khác nhau. Mục đích chính của XML là
đơn giản hóa việc chia sẻ dữ liệu giữa các hệ thống khác
nhau, đặc biệt là các hệ thống đƣợc kết nối với Internet.

Web Ontologoy
Language (OWL)

Một lớp ngôn ngữ biểu diễn tri thức và đƣợc sử dụng cho
việc định nghĩa và xây dựng các ontology.

Metadata

Siêu dữ liệu: dữ liệu dùng để mô tả dữ liệu, hỗ trợ trong việc
tìm kiếm và suy diễn tri thức trên dữ liệu.

Phases/Iterations

Các giai đoạn phát triển khác nhau của một dự án phần
mềm.

Requirement

Giai đoạn lấy yêu cầu từ khách hàng và lƣu lại dƣới dạng
văn bản.

Design

Giai đoạn thiết kế về mặt kĩ thuật cũng nhƣ giao diện, cơ sở
dữ liệu…


xi
Thuật ngữ (viết tắt)

Giải thích

Implementation

Giai đoạn thực thi.

Testing

Giai đoạn kiểm thử chƣơng trình.

Documentation

Giai đoạn viết tài liệu hƣớng dẫn sử dụng cho khách hàng.

Severity

Mức độ nghiêm trọng của lỗi phần mềm.

Cause Category

Phân loại lỗi phần mềm dựa trên nơi xuất phát/nguyên nhân
của nó.

Root cause

Nguyên nhân dẫn đến lỗi phần mềm.

Working Effort

Công sức bỏ ra để khắc phục sự cố do lỗi phần mềm gây ra
đƣợc đo lƣờng bằng số giờ bỏ ra để sửa chữa chúng.

Fixing Cost

Giá trị bỏ ra để sửa chữa lỗi phần mềm.

CostWeightage

Trọng số của mỗi lỗi phần mềm đƣợc tính tốn dựa trên
trọng số của Fixing Cost.

SeverityWeightage

Trọng số của mỗi lỗi phần mềm đƣợc tính tốn dựa trên
trọng số của Severity.

FinalWeightage

Trọng số tổng cộng của mỗi lỗi phần mềm.

Voting

Đánh giá của ngƣời sử dụng đối với mỗi tri thức.

View

Số lƣợt truy cập của ngƣời sử dụng.

Import

Quá trình đƣa dữ liệu vào cơ sở tri thức.


1

CHƢƠNG 1
TỔNG QUAN
1.1 Giới thiệu
Ngày nay, cùng với sự phát triển không ngừng của khoa học kĩ thuật hiện đại thì phần
mềm máy tính (gọi tắt là phần mềm) trở thành một phần không thể thiếu trong cuộc sống
hằng ngày của mỗi con ngƣời cũng nhƣ chi phối tất cả các hoạt động sản xuất khác.
Phƣơng tiện giao thông, máy móc, ngân hàng, siêu thị… tất cả đều cần đến sự hỗ trợ
cũng nhƣ điều khiển của phần mềm. Vì thế mà việc sản xuất ra những phần mềm có chất
lƣợng tốt với chi phí thấp và tốn ít thời gian đang đƣợc xem là vấn đề đƣợc quan tâm nhất
hiện nay.
Nhƣ chúng ta đã biết, để sản xuất đƣợc một phần mềm thì phải trải qua một qui trình
phức tạp bao gồm rất nhiều giai đoạn (phases/iterations) và cần sự tham gia của rất nhiều
ngƣời. Ở mỗi một giai đoạn đều yêu cầu phải có các chuyên gia, là những ngƣời có nhiều
kinh nghiệm cùng làm việc với nhau để đƣa ra các ý tƣởng sáng tạo, các ứng dụng khoa
học kĩ thuật để tạo nên một sản phẩm thành cơng. Trong khi đó khoa học kĩ thuật hiện đại
lại ln ln phát triển khơng ngừng, chính vì thế mà tri thức và kinh nghiệm đạt đƣợc
trong hoạt động sản xuất mềm đƣợc xem nhƣ là một tài sản hết sức q giá cho một tổ
chức nói riêng cũng nhƣ cho ngành cơng nghệ phần mềm nói chung. Tuy nhiên tri thức
sau khi đƣợc tạo ra bởi con ngƣời và lƣu trữ dƣới một hình thức nào đó cần đƣợc tổ chức
lại, qua một q trình xử lí và phân loại theo một mục đích nhất định để con ngƣời có thể
dễ dàng tiếp cận và sử dụng chúng một cách có hiệu quả. Cũng vì lí do đó mà nhu cầu
quản lí các tri thức trở thành một hoạt động không thể thiếu trong hoạt động sản xuất
phần mềm.
Việc xây dựng một cơ sở tri thức đƣợc xem là bƣớc đầu trong nhu cầu quản lí tri thức
trong hoạt động sản xuất phần mềm. Cơ sở tri thức chính là nơi tập hợp tất các tri thức
thu đƣợc từ kinh nghiệm trong các quá trình phát triển dự án nhằm hỗ trợ cho các nhân
viên trong tổ chức. Từ các dữ liệu thu thập đƣợc qua rất nhiều các quá trình phát triển dự
án, qua một quá trình lựa chọn, phân loại, xử lí, phân tích trở thành một tập hợp các tri
thức có thể chia sẻ và sử dụng một cách có hữu ích nhằm hỗ trợ phát triển hiệu quả các
dự án về sau.

2
Trong giới hạn của luận văn này chúng tôi chỉ quan tâm đến một yếu tố duy nhất có ảnh
hƣởng rất lớn đến chất lƣợng của một hoạt động phần mềm và cũng là một yếu tố tham
gia xuyên suốt trong một q trình sản xuất phần mềm, đó là lỗiphần mềm (software
defect) mà từ đây chúng tôi xin gọi tắt là lỗi.
Lỗi phần mềm là tất cả các lỗi xảy ra trong một chƣơng trình hay hệ thống máy tính dẫn
đến những kết quả khơng nhƣ mong muốn hoặc làm cho phần mềm chạy sai hồn tồn,
thậm chí ngƣng hoạt động. Bất kì một đội phát triển dự án phần mềm đều mong muốn
xây dựng đƣợc một phần mềm với số lƣợng các lỗi càng nhỏ càng tốt. Các rủi ro trong
một chƣơng trình phần mềm đƣợc phát hiện càng sớm thì chất lƣợng của phần mềm càng
đƣợc cải thiện đáng kể. Hơn thế nữa, việc xác định và sửa chữa các lỗi là công việc hết
sức tốn thời gian và chi phí. Tuy việc loại bỏ tất cả các lỗi ra khỏi một dự án phần mềm là
không thể nhƣng chúng ta có thể làm giảm mức độ trầm trọng và sự thiệt hại mà chúng
gây ra cho dự án của chúng ta.
Hiện nay, có rất nhiều cơng trình nghiên cứu về dự báo lỗi trong các sản phẩm phần
mềm, phần lớn dựa vào phân tích các lỗi đã từng xảy ra trong một số lƣợng lớn các dự
án, từ đó dự đốn đƣợc các lỗi cịn tồn tại trong một hệ thống phần mềm. Các nghiên cứu
này khơng nằm ngồi mục đích hỗ cho các lập trình viên và các nhà quản lí điều khiển
đƣợc qui trình phát triển phần mềm, liệu họ có nên dành thêm thời gian để tiếp tục tìm
kiếm và sửa lỗi hay có thể đƣa sản phẩm của mình bƣớc sang giai đoạn phát triển tiếp
theo.
Nhìn chung thì ngày nay các nghiên cứu chủ yếu phân tích lỗi theo 2 hƣớng đó là phân
loại (classification) và dự báo (prediction) nhằm xây dựng nên các mơ hình (model) mơ
tả đƣợc các lỗi trọng yếu thƣờng xảy ra và dự đoán đƣợc xu hƣớng các lỗi có khả năng sẽ
xảy ra trong tƣơng lai [3] [4] [6]. Tất cả các phân tích đó giúp cho lập trình viên có thể
phát hiện ra các lỗi có khả năng xảy ra và giúp cho ngƣời quản lí dự án có thể đánh giá và
nắm bắt đƣợc chất lƣợng của dự án, từ đó phân cơng nguồn lực để kiểm tra, phát hiện và
sửa chữa lỗi một cách phù hợp.

Bên cạnh đó cịn có một số cơng trình nghiên cứu về việc dự đốn các lỗi dựa trên mối
quan hệ của chúng sử dụng một số kĩ thuật phân tích dữ liệu (data mining) [5] và từ đó
cũng dự đốn đƣợc thời gian và cơng sức tƣơng ứng cần phải bỏ ra để sửa những lỗi đó.
Nói tóm lại là để trả lời cho những câu hỏi sau:


3
- Với những lỗi đang xảy ra trong một dự án phần mềm thì có những lỗi nào
khác có khả năng lớn cũng đang diễn ra hoặc sẽ xuất hiện
- Để sửa các lỗi đã xảy ra thì sẽ tốn bao nhiêu thời gian và nỗ lực tƣơng ứng

1.2

Mục tiêu

Xây dựng một cơ sở tri thức vừa đủ về các lỗi phát sinh trong quá trình sản xuất phần
mềm, bao gồm các thông tin về dạng lỗi, nguyên nhân dẫn đến lỗi, tỉ lệ phân bổ lỗi theo
chức năng hay tần suất xuất hiện. Thơng qua việc phân tích thơng tin lỗi và nguyên nhân
của chúng, đề xuất ra các giải pháp gợi ý hỗ trợ ngƣời dùng giải quyết các lỗi đó.
Tiếp theo đó sẽ xây dựng một cơ chế để ngƣời dùng có thể truy cập vào cơ sở tri thức đó,
có thể là một cơng cụ chỉ dừng lại ở một bản dùng thử (demo) để ngƣời dùng có thể sử
dụng thử và nhận xét đánh giá.

1.3

Đối tƣợng nghiên cứu

Phạm vi nghiên cứu chỉ giới hạn trong công ty phát triển phần mềm KMS Việt Nam 1.
Hiện nay công ty đang sử dụng một số công cụ để lƣu lại các lỗi xảy ra trong một dự án
nhƣ Issuetracker (JIRA 2), BugZilla 3, Qtrace 4… Các công cụ này hiện tại là một nơi

chứa thông tin về các lỗi kèm theo cơ chế để ngƣời sử dụng có thể tạo mới, sửa chữa và
truy xuất thơng tin. Ngồi ra mỗi cơng cụ cịn có các tính năng riêng biệt nhƣ gửi thƣ
thông báo, hỗ trợ ngƣời dùng tìm kiếm thống tin hiệu quả, có thể xuất ra các thông tin
thống kê và các lƣợc đồ hỗ trợ các nhà quản lí biết đƣợc tình hình sức khỏe của dự án …
Tuy nhiên các công cụ này chỉ dừng ở bƣớc lƣu trữ thông tin và thống kê thông tin nhằm
hỗ trợ các thành viên trong cùng một dự án theo dõi các lỗi xảy ra cho dự án nhất định.
Vì thế mà trong luận văn này chúng tôi muốn xây dựng nên một cơ sở tri thức mang tính
chất tổng quát hơn, các lỗi thu thập đƣợc từ các dự án phần mềm sau một quá trình phân
tích, đánh giá sẽ hình thành nên một cơ sở tri thức có thể chia sẻ và hỗ trợ cho tất cả các
dự án hiện tại cũng nhƣ trong tƣơng lai.

1


/>3
/>4
/>2


4

1.4

Phƣơng pháp nghiên cứu

Khảo sát hiện trạng chất lƣợng của các dự án phần mềm thông qua việc thu tập dữ liệu về
lỗi xảy ra trong tất cả các giai đoạn phát triển của một số dự án trong một số cơng ty phát
triển phần mềm.
Phân tích và phân loại lỗi dựa trên phƣơng pháp ODC (Orthogonal Defect Classification)
của IBM [7]. Lý do lựa chọn sử dụng phƣơng pháp này là vì nó thể hiện đƣợc mối quan

hệ ngun nhân và hệ quả khi phân loại lỗi trong qui trình phát triển phần mềm, từ đó ta
có thể đề ra các phƣơng án để có thể sửa chữa, giảm thiểu và thậm chí là có thể phịng
tránh đƣợc các lỗi có thể xảy ra trong q trình phát triển phần mềm. Cho đến nay có rất
nhiều phƣơng pháp và nghiên cứu về phân loại lỗi nhƣng phần lớn đều không thể hiện
đƣợc mối quan hệ nguyên nhân và hệ quả nhƣ phƣơng pháp ODC.
Dựa trên các kết quả phân tích từ phƣơng pháp ODC, phân tích nguyên nhân của các lỗi
bằng đồ thị xƣơng cá [4] cùng các hệ quả của nó (cause-effect relationship). Cũng từ đó,
đề xuất các phƣơng án đề xuất xử lí với các lỗi tƣơng ứng.
Dựa trên các thơng tin có đƣợc về lỗi sau bƣớc phân tích và đánh giá trên, xây dựng nên
một cơ sở tri thức về lỗi sử dụng một công cụ chính của web ngữ nghĩa đó là ontology.
Luận văn xây dựng nên một ontology về các lỗi trong quá trình phát triển phần mềm bao
gồm các thành phần có quan hệ với nhau về mặt ngữ nghĩa, sau đó dùng một cơ sở dữ
liệu với các mối quan hệ để hiện thực ontology và đồng thời cũng là một kho lƣu trữ dữ
liệu của cơ sở tri thức. Tiếp theo đó là việc hiện thực một ứng dụng web liến kết với cơ
sở dữ liệu thông qua ngôn ngữ truy vấn dữ liệu SQL, nhằm hỗ trợ một cơ chế duyệt và
tìm kiếm để ngƣời sử dụng có thể truy cập cơ sở tri thức đó.
Có thể thử nghiệm áp dụng sự hỗ trợ của cơ sở tri thức trong phạm vi của 1 dự án nhỏ
trong công ty KMS, sau đó đánh giá về khả năng hỗ trợ của nó trong việc giảm số lƣợng
lỗi hay giảm thời gian và công sức để giải quyết các lỗi trong dự án nhƣ thế nào.

1.5

Các cơng trình nghiên cứu liên quan

Trong tài liệu tham khảo số [4] ,một nghiên cứu của Sakthi Kumaresh và R Baskaran với
tựa đề là “Defect Analysis and Prevention for Software Process Quality Improvement”,
tác giả đã tập trung vào phân tích tất cả các lỗi thu thập đƣợc từ 5 dự án phần mềm dựa
trên cấp bậc phân loại đầu tiên của phƣơng pháp ODC, dựa vào đó đi tìm ngun nhân
chính gây ra lỗi, từ đó đề ra các ý tƣởng để phòng tránh để lỗi sẽ không xảy ra trong các

5
dự án tiếp theo. Ngồi ra, bài nghiên cứu cịn trình bày việc ứng dụng các ý tƣởng phịng
tránh lỗi nêu ra đã làm giảm số lƣợng các lỗi tƣơng ứng trong các dự án đƣợc đƣa ra thử
nghiệm nhƣ thế nào.
Sakthi Kumaresh và R Baskaran đã thu thập thông tin về lỗi từ 5 dự án đƣợc đƣa vào
nghiên cứu, sau đó tính tốn các số liệu sau:
- Số lƣợng dòng code (KLOC)
- Số lƣợng lỗi
- Số lƣợng thời gian tính theo đơn vị giờ mà tất cả nhân viên trong dự án phải
bỏ ra trong toàn bộ dự án
- Sau đó tính ra tỉ lệ số lỗi trên số lƣợng dòng code gọi là mật độ lỗi (defect
density):

Mật độ lỗi = Số lƣợng lỗi / (số lƣợng dòng code – 1)

Tiếp theo đó, bài nghiên cứu phân tích tất cả các lỗi thu thập đƣợc dựa trên cấp bậc phân
loại đầu tiên của phƣơng pháp ODC đó là phân loại lỗi dựa trên các giai đoạn phát triển
của dự án:
- Giai đoạn phân tích yêu cầu (Requirement)
-

Giai đoạn thiết kế (Design)
Giai đoạn lập trình (Code)
Giai đoạn thiết kế giao diện (GUI)
Đoạn viết tài liệu hƣớng dẫn sử dụng (Documentation)

Sau đó là bƣớc phân tích ngun nhân lỗi dựa trên đồ thị xƣơng cá và đề ra các ý tƣởng
phịng tránh lỗi.
Kế đến đó là bƣớc thử nghiệm đánh giá việc ứng dụng các ý tƣởng phòng tránh lỗi vào

một số dự án tƣơng tự 5 dự án đã đƣa ra nghiên cứu, sau đó thu thập thơng tin về lỗi một
lần nữa và tính tốn lại các con số trên nhƣ: tần suất lỗi, số lƣợng lỗi, số lƣợng dòng
code, số lƣợng thời gian bỏ ra cho dự án ….và so sánh với năm dự án ban đầu để thấy


6
đƣợc tác dụng và ý nghĩa của các ý tƣởng phòng tránh lỗi (defect prevention) đối với việc
nâng cao chất lƣợng của dự án phần mềm.
Qua nghiên cứu trên ta rút ra đƣợc việc phân tích và nghiên cứu lỗi khơng những giúp
nâng cao chất lƣợng dự án mà cịn giúp cho các thành viên trong dự án phần mềm học
hỏi đƣợc kinh nghiệm từ các lỗi và các sai lầm từ của các thành viên thuộc dự án khác, từ
đó rút kinh nghiệm và có những phƣơng án phù hợp để phòng tránh lỗi. Việc phòng tránh
đƣợc các lỗi hoặc phát hiện sớm các lỗi trong dự án và kịp thời có phƣơng án sữa chữa
phù hợp khơng những sẽ tiết kiệm đƣợc rất nhiều thời gian và công sức cho dự án mà cịn
góp phần đáng kể vào việc làm tăng chất lƣợng của dự án.
Tuy nhiên, bài nghiên cứu trên chỉ thực thi phƣơng pháp ODC ở cấp bậc đơn giản nhất để
phân loại các lỗi, bài nghiên cứu cũng đã nêu ra hƣớng phát triển mới đó là phân loại lỗi
thơng qua các cấp độ tiếp theo của phƣơng pháp ODC nhƣ tác động của lỗi (Defect
Impact), nguồn gốc kích hoạt lỗi (Defect Trigger)… để hiểu rõ, hiểu sâu hơn về lỗi xảy ra
trong tất cả các giai đoạn phát triển của dự án.
Tài liệu số 5 (“Software Defect Association Mining and Defect Correction Effort
Prediction”) trình bày một phƣơng pháp dựa trên kĩ thuật khai thác dữ liệu (data mining)
để đƣa ra các dự đoán về mối liên hệ giữa các lỗi và nỗ lực tƣơng ứng phải bỏ ra để sữa
chữa chúng. Nói tóm lại là để trả lời cho những câu hỏi sau:
- Với những lỗi đang xảy ra trong một dự án phần mềm thì có những lỗi nào
khác có khả năng lớn cũng đang diễn ra hoặc sẽ xuất hiện. Ví dụ: nếu lỗia và
lỗib xuất hiện thì có thể dự đốn đƣợc rằng lỗic cũng sẽ xuất hiện sau đó.
- Để sửa các lỗiđã xảy ra thì sẽ tốn bao nhiêu thời gian và nỗ lực tƣơng ứng
Cơng trình nghiên cứu này nhằm hỗ trợ các lập trình viên trong việc phát hiện ra lỗi và
giúp cho các nhà quản lí phân cơng nhân lực trong dự án cho q trình kiểm thử sản

phẩm một cách hiểu quả hơn. Các nhà nghiên cứu đã ứng dụng phƣơng pháp mà họ đề
nghị vào một số lƣợng lớn các dữ liệu về lỗi đƣợc cung cấp bởi SEL (NASA/GSFC
Software Engineering Laboratory – nơi lưu trữ và truy vấn dữ liệu về công nghệ phần
mềm cho tổ chức NASA Goddard Space Flight Center) đƣợc thu thập từ 200 dự án trong
vòng hơn 15 năm. Kết quả thu đƣợc cho thấy với các dự đoán dựa trên mối liên hệ của lỗi
độ chính xác đạt đƣợc của sự dự đoán là rất cao, 95.98% và tỉ lệ dự đoán sai là rất thấp,
2.84%. Tƣơng tự nhƣ thế, độ chính xác của việc dự đốn nỗ lực bỏ ra để sửa chữa lỗi
cũng rất cao, 94.69%. Bên cạnh đó, tác giả cịn so sánh phƣơng pháp dự đoán nỗ lực bỏ


7
ra để sửa chữa lỗi với các phƣơng pháp khác nhƣ phƣơng pháp Nạve Bayes thì độ chính
xác tăng lên là 23%.
Tài liệu tham khảo số [6] “Software Defect Prediction Models for Quality Improvement”.
Bài nghiên cứu chỉ ra sự ảnh hƣởng rất lớn của lỗi đối với chất lƣợng của một dự án phần
mềm và trình bày cách thức thực thi của một số các mơ hình dự báo lỗi đã dẫn đến việc
giảm số lƣợng các lỗi xuất hiện trong dự án nhƣ thế nào. Các mơ hình dự đốn mà các tác
giả phân tích bao gồm:
- Mơ hình dự đoán dựa trên số đo độ phức tạp và kích thƣớc (Prediction Model
using size and complexity metrics) là một mơ hình dự đốn lỗi đƣợc sử dụng
phổ biến nhất hiện nay. Nó dựa trên số lƣợng các dịng code (LOC) của dự án
và mơ hình đo độ phức tạp đƣợc phát triển bởi McCabe.
- Mơ hình dựa trên Machine Learning (Machine Learning Based Models) bao
gồm một số mơ hình sau:
o Mơ hình xác suất dự đốn lỗi dựa trên Bayesian Belief Network (The
Probabilistic Model for Defect Prediction using Bayesian Belief
Network)
o Mơ hình dự đốn dựa trên thuật tốn di truyền (Defect Prediction
Models Based on Genetic Algorithms)
o Mơ hình xác suất dự đoán lỗi dựa trên mạng thần kinh nhân

tạo(Software Defect Prediction Models using Artificial Neural
Network)
- Mơ hình dự báo dựa trên tần suấtlỗi (Defect Density Prediction Model)
o Mơ hình hóa chất lƣợng xây dựng dự án để dự báo tần suấtlỗi
(Constructive Quality Modeling for Defect Density Prediction)
o Mơ hình dự đốn lỗi dựa trên 6 tiêu chí (Defect Prediction Model based
on Six Sigma Metrics)
Nhìn chung thì ngày nay các nghiên cứu chủ yếu phân tích sofware lỗi theo 2 hƣớng đó là
phân loại (classification) và dự báo (prediction) nhằm xây dựng nên các mơ hình (model)
mơ tả đƣợc các lỗi trọng yếu thƣờng xảy ra và dự đoán đƣợc xu hƣớng các lỗi có khả
năng sẽ xảy ra trong tƣơng lai từ đó đề ra các phƣơng pháp để ngăn chặn sự xảy ra của
các lỗi (defect prevention) [3] [4] [5] [6]. Tất cả các phân tích đó giúp cho lập trình viên
có thể phát hiện ra các lỗi có khả năng xảy ra và giúp cho ngƣời quản lí dự án có thể đánh


8
giá và nắm bắt đƣợc chất lƣợng của dự án, từ đó phân cơng nguồn lực để kiểm tra, phát
hiện và sửa lỗi một cách phù hợp. Nhìnchung lại thì tất cả các nỗ lực đó khơng nằm ngồi
mục tiêu là nâng cao chất lƣợng trong hoạt động cũng nhƣ trong quản lí của một dự án
phần mềm.
Qua q trình tìm hiểu các cơng trình nghiên cứu trƣớc đó nhƣ đã trình bày ở trên, luận
văn chọn cơng trình nằm trong tài liệu số [4] đã đƣợc trình bày trong phần đầu tiên của
danh mục này, các cơng trình nghiên cứu liên quan, làm định hƣớng cho nghiên cứu của
mình. Nhƣ đã trình bày, bài nghiên cứu trên chỉ thực thi phƣơng pháp ODC ở cấp bậc
đơn giản nhất để phân loại các lỗi, để hiểu rõ, hiểu sâu hơn về lỗi xảy ra trong tất cả các
giai đoạn phát triển của dự án, chúng ta phải phân loại lỗi thông qua các cấp độ tiếp theo
của phƣơng pháp ODC nhƣ nguồn gốc kích hoạt lỗi, tác động lỗi... Đó cũng là vấn đề mà
luận văn đặt ra và tiếp tục phát triển.

9

CHƢƠNG 2
CƠ SỞ LÝ THUYẾT
2.1

Cơ sở lí thuyết về lỗi

2.1.1 Lỗi
Lỗi là tất cả các lỗi xảy ra trong một chƣơng trình hay hệ thống máy tính dẫn đến những
kết quả không nhƣ mong muốn hoặc làm cho phần mềm chạy sai hồn tồn, thậm chí
ngƣng hoạt động. Một phần mềm có chất lƣợng cao là một phần mềm với số lƣợng các
lỗi càng nhỏ càng tốt. Vì thế các lỗi trong một chƣơng trình phần mềm đƣợc phát hiện
càng sớm thì chất lƣợng của phần mềm càng đƣợc cải thiện đáng kể.Hơn thế nữa, việc
xác định và sửa chữa các lỗi là một công việc hết sức tốn thời gian và chi phí. Tuy việc
loại bỏ tất cả các lỗi ra khỏi một dự án phần mềm là không thể nhƣng chúng ta có thể làm
giảm mức độ trầm trọng và sự thiệt hại mà chúng gây ra cho dự án[6] .

2.1.2 Mơ hình phân loại lỗi ODC
Trƣớc khi có mơ hình ODC thì đã tồn tại hai kĩ thuật khác thƣờng đƣợc sử dụng để phân
tích dữ liệu về lỗi thu thập đƣợc từ các dự án, đó là Mơ hình Thống kê Lỗi (Statistical
Defect Modeling) và Phƣơng pháp Phân tích Thơng thƣờng (Casual Analysis)[7]. Trong
đó, Mơ hình Thống kê Lỗisử dụng phƣơng pháp thống kê để phân tích lỗi bằng cách xem
mỗi lỗi nhƣ là một mẫu thử lấy ngẫu nhiên trong một tổ hợp đƣợc đƣa vào mơ hình thống
kê, cịn Phƣơng Pháp Phân Tích Thơng Thƣờng thì xem mỗi lỗi xảy ra là duy nhất và tìm
ra nguyên nhân của từng lỗi một. Cả hai phƣơng pháp này hiện nay đều không đƣợc sử
dụng phổ biến bởi vìđối với phƣơng pháp thứ nhất thì các kết quả có đƣợc chỉ dựa trên
các số liệu thống kê trên số lƣợng các lỗi, nhƣ thế không đủ để cải thiện qui trình phát
triển dự án, trong khi đó đối với phƣơng pháp thứ hai thì việc phân tích từng lỗi cụ thể và
tìm ngun nhân của nó rất tốn thời gian và chi phí, đó là chƣa kể đến kết quả thu đƣợc

từ các phƣơng pháp này rất khó có thể mở rộng trong tƣơng lai.
ODC (Orthogonal Defect Classification) [7] do IBM phát triển vào những năm 1990s
bởi Ram Chillarege. ODC là một phƣơng pháp để phân loại và phân tích lỗi trong tất cả
các giai đoạn phát triển của một dự án phần mềm.ODC phân loại lỗi dựa trên cách thức
sửa chữa lỗivà phân tích lỗi qua từng giai đoạn giai đoạn phát triển của một sản phẩm
phần mềm. ODC cung cấp một phƣơng pháp đo lƣờng để có thể rút ra đƣợc các đặc tính


10
quan trọng của lỗi và cho phép ta phân tích đƣợc nguyên nhân của lỗi dựa trên mối quan
hệ nguyên nhân và hệ quả. ODC dựa trên một giả thuyết rằng trong suốt vịng đời phát
triển của dự án thì mỗi giai đoạn sẽ xuất hiện các loại lỗi khác nhau và nếu quá nhiều lỗi
ở giai đoạn khác xuất hiện ở giai đoạn này là biểu hiện những vấn đề bất bình thƣờng sẽ
gây ra khó khăn cho dự án.
Phƣơng pháp ODC mô tả sự phân bổ của các loại lỗi trong các giai đoạn phát triển của dự
án nhằm thể hiện sự phát triển của các loại lỗi trong qui trình phát triển phần mềm, nhƣ
hình 2-1.

Hình 2-1: Mơ hình mơ tả sự phân bổ của các lỗi qua các giai đoạn phát triển của dự án [7]

Ngoài ra phƣơng pháp ODC cịn đƣa ra đƣợc các nhóm phân loại lỗi (defect
categories)khơng chồng chéo, nhập nhằng và hồn tồn độc lập với nhau. Bên cạnh đó
ODC cũng xác định một tập nhỏ các thuộc tính của lỗi (defect attributes) để cung cấp
một phƣơng tiện để đo lƣờng các mối quan hệ của lỗi bao gồm:
Kiểulỗi (Defect Type): đánh giá đặc điểm của lỗidựa trên nhữngsự thay đổi để sửa
chữa chúng.


11
Nguồn gốc kích hoạt lỗi (Defect Trigger): đánh giá đặc điểm của lỗi dựa trên

những nguyên nhân, xúc tác dẫn đến lỗi.
Tác động của lỗi (Defect Impact): đo sự tác động của lỗi trên phƣơng diện tác
động lên ngƣời sử dụng.

2.1.3 Kiểu lỗi (Defect Type):
ODC chia lỗi thành 8 loại khác nhau, bao gồm:
Giao diện (Interface): lỗi xảy ra là kết quả của những vấn đề về giao tiếp giữa các
thành phần của hệ thống, các hệ thống con, các mô-đun, hệ điều hành hoặc là các
thiết bị cài đặt nên cần phải có sự thay đổi ví dụ nhƣ sử dụng các điều khiển
(control blocks), các chỉ gọi (call statement), sử dụng bộ nhớ chia sẻ (shared
memory) …
Chức năng (Function):lỗi xảy ra do hiện thực thiếu sót hoặc khơng đúng các
chức năng quan trọng của phần mềm nhƣ giao diện giao tiếp với ngƣời dùng, giao
diện của sản phẩm, cách giao tiếp với các cấu trúc phần cứng, cấu trúc dữ liệu của
hệ thống …
Xây Dựng/Đóng gói/Kết hợp (Build/Package/Merge): cáclỗi gặp phải trong qui
trình xây dựng hệ thống và nguyên nhân gây ra xuất phát từ thƣ viện hệ thống,
việc quản lí sự thay đổi hoặc sự kiểm sốt phiên bản đƣợc liệt kê vào phân loại
này.
Gán giá trị (Assignment): lỗi xảy ra do kết quả của việc một giá trị bị gán sai
hoặc thậm chí khơng đƣợc gán gì cả. Lƣu ý rằng nếu việc sữa chữa một lỗi mà đòi
hỏi phải sữa chữa một loạt các lỗi gán giá trị thì lỗi đó có khả năng thuộc phân loại
Algorithm.
Tài liệu (Documentation): các lỗi xảy ra thuộc phân loại này là kết quả của
những lỗi sai liên quan đến tài liệu nhƣ tài liệu hƣớng dẫn cho ngƣời sử dụng mô
tả sai, tài liệu hƣớng dẫn cài đặt khơng đúng, các chú thích trong code sai…Chú ý
là khơng nên nhầm lẫn loại lỗi này với lỗi hoặc thiếu sót trong các tài liệu yêu cầu
hoặc thiết kế bởi vì nó rất có thể là một lỗi thuộc Function hoặc Interface.
Kiểm tra (Checking): lỗi xảy ra là kết quả của các sai sót trong q trình kiểm tra
hoặc xác nhận các thông số dữ liệu. Lƣu ý rằng nếu việc sữa chữa một lỗi mà đòi