khảo sát và đánh giá sản phẩm phần mềm theo các tiêu chuẩn chất lượng

ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
VÀ TRUYỀN THÔNG


NÔNG THỊ NHÀN


KHẢO SÁT VÀ ĐÁNH GIÁ SẢN PHẨM
PHẦN MỀM THEO CÁC TIÊU CHUẨN
CHẤT LƯỢNG


LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH




THÁI NGUYÊN - 2012
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
VÀ TRUYỀN THÔNG

NÔNG THỊ NHÀN


KHẢO SÁT VÀ ĐÁNH GIÁ SẢN PHẨM
PHẦN MỀM THEO CÁC TIÊU CHUẨN
CHẤT LƯỢNG

Chuyên ngành: Khoa học máy tính
Mã số: 60 48 01
LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

NGƯỜI HƯỚNG DẪN KHOA HỌC
PGS. TSKH NGUYỄN XUÂN HUY


Thái Nguyên - 2012

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

i
LỜI CAM ĐOAN

Tôi xin cam đoan luận văn này là công trình nghiên cứu, tìm hiểu và tham
khảo của riêng tôi. Các số liệu trong luận văn là trung thực.

Tác giả


Nông Thị Nhàn
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

ii
LỜI CẢM ƠN
Luận văn này được hoàn thành tại trường Đại học Công nghệ Thông tin và
Truyền thông - Đại học Thái Nguyên. Dưới sự hướng dẫn của PGS.TSKH
NGUYỄN XUÂN HUY. Tác giả xin bày tỏ lòng kính trọng và biết ơn sâu sắc tới
thầy về sự tận tình hướng dẫn trong suốt thời gian tác giả làm luận văn.

Tác giả xin bày tỏ lòng kính trọng và biết ơn tới PGS.TS Nguyễn Thiện Luận
đã cung cấp một số tài liệu trong quá trình làm luận văn.
Trong quá trình học tập tại trường Đại học Công nghệ Thông tin và Truyền
thông - Đại học Thái Nguyên tác giả thường xuyên nhận được sự quan tâm giúp đỡ,
đóng góp ý kiến của các thầy cô trực tiếp giảng dạy và các cán bộ, giáo viên trong
trường. Tác giả xin bày tỏ lòng biết ơn sâu sắc đến những thầy cô đó.
Tác giả xin bày tỏ lòng biết ơn tới Ban Giám Hiệu, các bạn đồng nghiệp
trường Trung học Phổ thông Quang Trung đã tạo điều kiện sắp xếp công việc, giúp
đỡ tác giả trong thời gian học tập và làm luận văn.
Xin chân thành cảm ơn anh chị em học viên lớp CAO HỌC K9A đã giúp đỡ,
động viên, khích lệ tác giả trong quá trình học tập và nghiên cứu.
Luận văn sẽ không hoàn thành được nếu không có sự quan tâm, động viên
của người thân trong gia đình tác giả. Đây là món quà tinh thần, tác giả xin gửi tặng
gia đình thân yêu của mình với lòng biết ơn sâu sắc.

Tác giả
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

iii
MỤC LỤC
Lời cam đoan i
Lời cảm ơn ii
Mục lục iii
Danh mục các từ viết tắt v
Danh mục các hình ảnh, hình vẽ vi
MỞ ĐẦU 1
Chƣơng 1. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM, CÁC TIÊU
CHÍ ĐÁNH GIÁ SẢN PHẨM PHẦN MỀM 4
1.1. Các thuật ngữ 4
1.2. Quy trình phát triển phần mềm 6

1.2.1. Các giai đoạn của quy trình phát triển phần mềm 6
1.2.1.1. Nghiên cứu sơ bộ 7
1.2.1.2. Phân tích hệ thống phần mềm 7
1.2.1.3. Thiết kế hệ thống 8
1.2.1.4. Xây dựng phần mềm 8
1.2.1.5. Thử nghiệm hệ thống 9
1.2.1.6. Thực hiện, triển khai 9
1.2.1.7. Bảo trì, nâng cấp 9
1.2.2. Các mô hình vòng đời phần mềm 10
1.2.2.1. Mô hình tăng trưởng (growth model) 10
1.2.2.2. Mô hình đồng bộ và ổn định (Synchronize-And-
Stabilize Model) 11
1.2.2.3. Mô hình hướng đối tượng (Object-Oriented model) 12
1.3. Chất lượng phần mềm 12
1.4. Đánh giá phần mềm 13
1.4.1. Tầ m quan trọ ng của việc đánh giá chấ t lượ ng phần mềm 14
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

iv
1.4.2. Một số mô hình đánh giá chất lượng phần mềm 15
1.4.2.1. Mô hình ISO/IEC-9126 15
1.4.2.2. Mô hình ISO/IEC-14598 19
1.4.2.3. Một số mô hình khác 23
1.5. Các độ đo chất lượng phần mềm - Metrics (ISO/IEC 9126-2) 25
1.5.1. Độ đo trong 26
1.5.2. Độ đo ngoài 27
Chƣơng 2. PHƢƠNG PHÁP ĐÁNH GIÁ SẢN PHẨM PHẦN
MỀM THEO TIÊU CHUẨN CHẤT LƢỢNG 29
2.1. Phân loại phần mềm 29
2.1.1. Phân loại theo phương thức hoạt động 29

2.1.2. Phân loại theo khả năng ứng dụng 30
2.1.3. Phân loại theo nhu cầu của người dùng 30
2.2. Độ đo ngoài cho sản phẩm phần mềm 31
2.3. Các tiêu chí đánh giá các nhóm phần mềm 43
2.3.1. Nhóm phần mềm Quản lý giáo dục 44
2.3.2. Nhóm phần mềm Kế toán - Tài chính 46
2.3.3. Nhóm phần mềm tiện ích diệt virus 50
Chƣơng 3. XÂY DỰNG MỘT SỐ TIÊU CHUẨN CHẤT LƢỢNG
PHẦN MỀM 55
3.1. Bài toán quản lý trường học và những phần mềm ứng dụng. 55
3.2. Đánh giá Phần mềm Quản lý trường học - V.EMIS 57
3.2.1. Tổng quan về V.EMIS 57
3.2.2. Đánh giá phần mềm V.EMIS (V.EMIS.Student) 59
3.2.3. Xây dựng tiêu chí đánh giá phần mềm V.EMIS
(V.EMIS.Student) 63
KẾT LUẬN VÀ ĐỀ NGHỊ 67
TÀI LIU THAM KHẢO 68
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

v
DANH MỤC CÁC TỪ VIẾT TẮT
Từ viết
tắt
Diễn giải
Ý nghĩa
ISO
The International
Organisation for
Standardisotion
Tổ chức quốc tế về tiêu chuẩn hóa

trong các lĩnh vực sản xuất, thương
mại và thông tin.
IEC
The International
Electrotechnical
Commission
Uỷ ban Kỹ thuật Điện Quốc tế được
thành lập năm 1906.
ISO/IEC
The International
Organisation for
Standardisotion / The
International
Electrotechnical
Commission
Sự hợp tác giữa ISO và IEC để thành
lập ra Ủy Ban kỹ thuật chung.
IEEE
Instituse of Electrical and
Electronic Engineers
Tổ chức khoa học nghề nghiệp - Hỗ
trợ các hoạt động nghiên cứu khoa
học, thúc đẩy sự phát triển Khoa học
Công nghệ trong các lĩnh vực Điện tử.
Viễn thông, Công nghệ Thông tin…

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

vi
DANH MỤC CÁC HÌNH ẢNH, HÌNH VẼ

Hình 1.1. Mô hình chất lượng ISO/IEC 9126-1 18
Hình 1.2. Qui trình kiể m tra đánh giá sản phẩm phần mềm 19
Hình 1.3. Thang đo chất lượng 21
Hình 1.4. Mối liên hệ giữa tiêu chuẩn ISO 9126 và ISO 14598 23
Hình 3.1. Giao diện chính chương trình V.EMIS.Student phiên bản 1.1.4 59
Hình 3.2. Giao diện chức năng “Nhập danh sách học sinh trúng tuyển” 60
Hình 3.3. Giao diện chức năng “Nạp và sửa hồ sơ ban đầu” 60
Hình 3.4. Giao diện chức năng “Phân phòng thi tự động” 61

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

1
MỞ ĐẦU
Cơ sở khoa học của đề tài
Khi nói đến chất lượng phần mềm, có nhiều định nghĩa tùy theo cách nhìn
khác nhau. Từ cách nhìn của khách hàng, chất lượng được xác định là việc đáp ứng
nhu cầu và đạt tới sự thỏa mãn; Từ cách nhìn của người phát triển, phần mềm được
thiết kế tốt và sản phẩm tuân thủ theo thiết kế đó (đáp ứng yêu cầu đặc tả chức
năng); Ngoài ra chất lượng có thể được xác định như quy trình hiệu quả tạo ra sản
phẩm mà không có lỗi nào và cung cấp giá trị đo được cho những người tạo ra sản
phẩm và người dùng nó. Còn theo định nghĩa hình thức về Chất lượng phần mềm
của Tổ chức Tiêu chuẩn quốc tế ISO trong Bộ Tiêu chuẩn 8402: “Chất lượng là khả
năng đáp ứng toàn diện nhu cầu của người sử dụng về tính năng cũng như công
dụng được nêu ra một cách tường minh hoặc không tường minh trong những ngữ
cảnh xác định”. Những quan niệm và cách nhìn về chất lượng phần mềm nêu trên
có thể đầy đủ nhưng thiếu hẳn yếu tố định lượng.
Chất lượng phần mềm luôn là mối quan tâm hàng đầu của người sử dụng. Vì
vậy, rất cần có những tiêu chí đánh giá cụ thể và phương pháp đo đạc mang yếu tố
định lượng. Đề tài mong muốn đề xuất các tiêu chí đánh giá phần mềm, giúp khách

hàng cũng như người sử dụng có thể đánh giá khách quan về chấ t lượng phần mềm
sử dụng trong thực tế.
Mục tiêu và nhiệm vụ của luận văn
Đề xuất những tiêu chuẩn chung để đánh giá một số nhóm phần mềm từ việc
nghiên cứu, tìm hiểu các tiêu chuẩn đánh giá phần mềm đã có, ý nghĩa của các tiêu
chuẩn đó. Ngoài ra, đề tài tìm hiểu quy trình, phương pháp đánh giá phần mềm, từ
đó áp dụng thử nghiệm để đánh giá một phần mềm cụ thể.
Các tổ chức tiêu chuẩn quốc tế như ISO, IEEE, đã công bố các bộ chu ẩn
gồ m cá c tiêu chí đánh giá chất lượng sản phẩm phần mềm như:
a. ISO 9126: Software engineering Product quality
b. ISO 14598: Information technology Software product evaluation
c. ISO 12119: Software Packages - Quality Requirement and Testing
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

2
d. ISO 9000-3: Quality Management and Quality Assurance Standards- part 3
e. IEEE Std 1061-1992: Standard for Software Quality Metrics Methodology
Trong mỗi bộ chuẩn nêu trên, không phải tất cả đều có thể áp dụng để đánh
giá cho mọi phần mềm. Trong mỗi bộ chuẩn chúng ta chỉ có thể áp dụng một phần
nhỏ phù hợp với mỗi nhóm phần mềm khác nhau. Vì vậy, cần có các tiêu chí theo
một tiêu chuẩn chung, có mức tương đương với quốc tế để áp dụng. Trong phạm vi
đề tài luận văn, với mong muốn tìm hiểu về các tiêu chuẩn, quy trình, phương pháp
đánh giá chất lượng phần mềm, giúp khách hàng cũng như người sử dụng có thể
đánh giá khách quan về chấ t lượ ng phần mềm sử dụng trong thực tế, tôi chọn đề tài
"Khảo sát và đánh giá sản phẩm phần mềm theo các tiêu chuẩn chất lượng".
Đối tƣợng và phạm vi nghiên cứu
Nghiên cứu, tìm hiểu các tiêu chí đánh giá chất lượng phần mềm của các tổ
chức tiêu chuẩn trong nước và quốc tế; Khảo sát một số phần mềm ứng dụng; Áp
dụng thử nghiệm đánh giá chất lượng cho một phần mềm cụ thể.
Phƣơng pháp nghiên cứu

Tìm hiểu các tiêu chí đánh giá chất lượng sản phẩm phần mềm thông qua
việc thu thập, tổng hợp các sách, các bài báo, các tài liệu trên mạng bằng tiếng Việt,
tiếng Anh.
Nghiên cứu các tiêu chuẩn, hướng dẫn của các tổ chức tiêu chuẩn quốc tế
(ISO/IEC, IEEE ) về đánh giá chất lượng sản phẩm phần mềm qua các bộ chuẩn.
Vận dụng thử nghiệm các tiêu chí đánh giá cho một phần mềm cụ thể.
Cấu trúc và nội dung chính của luận văn
Cấu trúc và nội dung chính của luận văn gồm:
- Phần mở đầu.
- Chương 1. Quy trình phát triển phần mềm, các tiêu chí đánh giá sản phẩm
phần mềm.
Chương này trình bày tổng quan về quá trình phát triển phần mềm; Chất lượng
phần mềm; Thông qua một số mô hình đánh giá chất lượng phần mềm của các tổ chức
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

3
Tiêu chuẩn quốc tế, trình bày phương pháp và các tiêu chí đánh giá của các tổ chức đó;
Trình bày độ đo các tiêu chí chất lượng phần mềm theo ISO/IEC 9126-2.
- Chương 2. Phương pháp đánh giá sản phẩm phần mềm theo tiêu chuẩn chất lượng.
Chương này chia nhóm, phân loại các loại phần mềm khác nhau; Trình bày
đề xuất về độ đo ngoài cho sản phẩm phần mềm; Khảo sát và đề xuất phương pháp
đánh giá phần mềm theo tiêu chuẩn chất lượng cho một số loại phần mềm; Chi tiết
thang điểm cho từng tiêu chí đánh giá cụ thể.
- Chương 3. Xây dựng một số tiêu chuẩn chất lượng phần mềm.
Đặt vấn đề cho bài toán Quản lý trong trường học hiện nay; Nêu những
phần mềm được ứng dụng cho bài toán đó và nhu cầu cần được đánh giá; Áp dụng
các phương pháp được đề xuất ở Chương 2, đánh giá Phần mềm Quản lý trường
học V.EMIS; Xây dựng một số tiêu chuẩn của Phần mềm Quản lý trường học
V.EMIS.
- Phần kết luận và hướng phát triển.

- Tài liệu tham khảo.














Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

4
Chƣơng 1
QUY TRÌNH PHÁT TRIỂN PHẦN MỀM, CÁC TIÊU CHÍ ĐÁNH GIÁ
SẢN PHẨM PHẦN MỀM
1.1. Các thuật ngữ
Chất lượng: Là một tập hợp các tính chất và đặc trưng của sản phẩm tạo ra
cho nó khả năng thỏa mãn nhu cầu đã được nêu ra hoặc còn tiềm ẩn.
Chất lượng ngoài: Là toàn bộ các đặc điểm của sản phẩm phần mềm từ góc
độ của người đánh giá phần mềm độc lập.
Chất lượng phần mềm: Là sự đáp ứng các nhu cầu chức năng, sự hoàn thiện
và các chuẩn (đặc tả) được phát triển.
Chất lượng trong: Là tổng hợp của tất cả các đặc điểm của sản phẩm phần
mềm từ góc độ của người phát triển phần mềm.

Chất lượng sử dụng: Là cách nhìn của người sử dụng về chất lượng sản
phẩm phần mềm khi nó được cài đặt trong một môi trường và ngữ cảnh cụ thể.
Đánh giá phần mềm: Tập hợp các tiêu thức xác định chất lượng phần mềm
và các phương pháp xác định tiêu thức này.
Đo đạc: Là quá trình gán một giá trị hoặc phân loại cho một thực thể để mô
tả một thuộc tính của thực thể.
Luật đo (metric): Là phương pháp đo, cũng như thang đo dùng trong các
phép đo đạc.
Mô hình chất lượng: Là tập hợp các tiêu chuẩn dùng để chỉ ra các yêu cầu về
chất lượng cũng như đánh giá chất lượng của sản phẩm phần mềm.
Phần mềm: là những chương trình điều khiển các chức năng phần cứng và
hướng dẫn phần cứng thực hiện các tác vụ của mình.
Quy trình: Là phương pháp thực hiện hoặc các bước sản xuất ra sản phẩm.
Sản phẩm phần mềm: Là tập hợp các chương trình máy tính, thủ tục, tài liệu
liên quan, cũng như dữ liệu đi kèm.
Tiêu chí: là bộ tiêu chuẩn dùng để kiểm định hay để đánh giá một đối tượng,
mà bao gồm các yêu cầu về chất lượng, mức độ, hiệu quả, khả năng, tuân thủ các
qui tắc và qui định, kết quả cuối cùng và tính bền vững của các kết quả.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

5
Tiêu chuẩn: Là những quy định thống nhất được xây dựng theo một thể thức
nhất định do một cơ quan có thẩm quyền ban hành để bắt buộc hay khuyến khích áp
dụng cho các bên liên quan.
Tiêu chuẩn hóa: Là hoạt động thiết lập các điều khoản để sử dụng chung và
lặp đi lặp lại đối với những vấn đề thực tế hoặc tiềm ẩn nhằm đạt được mức độ trật
tự tối ưu trong những khung cảnh nhất định.
Tính an ninh, an toàn: Là khả năng của sản phẩm phần mềm bảo vệ các
thông tin và các dữ liệu khi bị xâm nhập bất hợp pháp.
Tính dung thứ được: Kết hợp các khả năng mở rộng chương trình, khả năng

thích ứng và tính tiện lợi.
Tính dời chuyển được: Là những thuộc tính liên quan đến chi phí vận chuyển
một sản phẩm phần mềm từ ổ cứng gốc đến ổ cứng khác hoặc từ một môi trường
hoạt động này đến môi trường hoạt động khác.
Tính đơn giản: Mức độ dễ hiểu của một chương trình.
Tính hiểu được: Là khả năng của sản phầm phần mềm cho phép người sử
dụng hiểu được phần mềm có thích hợp hay không và sử dụng nó như thế nào.
Tính không ổn định: Là các thuộc tính liên quan đến các văn bản thủ tục khi
sản phẩm phần mềm được thay đổi thường xuyên.
Tính mềm dẻo: Nỗ lực cần để cải biên một chương trình là chấp nhận được.
Tính ổn đinh: Là khả năng của sản phẩm phần mềm tránh được các tác
động bất ngờ từ các cải biên của phần mềm.
Tính phổ biến: Mức độ tiềm năng trình ứng dụng của các bộ phận trong
chương trình.
Tính thẩm tra được: Là không phụ thuộc vào các trình ứng dụng hay các bộ
phận được kiểm tra.
Tính thiết thực: Là mức độ sản phẩm các công việc thích hợp được chuyển
tiếp tới các chức năng hợp thức dưới các điều kiện hoặc tình huống khác thường.
Tính thử nghiệm được: Là khả năng của sản phẩm phần mềm cho phép cải
biên nó, và quá trình thử nghiệm không ảnh hưởng đến cấu hình và các bộ phận
được tạo ra.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

6
Tính tiện ích: Là mức độ cho phép nhiều người sử dụng truy cập và sử dụng
phần mềm ở các kiểu khác nhau.
Tính tiện lợi: Là khả năng của sản phẩm phần mềm trở nên dễ hiểu, dễ học,
dễ sử dụng và hấp dẫn người sử dụng.
Tính tin cậy được: Khả năng của hệ thống có thể cung cấp cho người sử dụng
các thông tin về lỗi dịch vụ.

Tính toàn vẹn: Có thể khống chế được việc truy cập của những người không
được phép sử dụng phần mềm và dữ liệu.
1.2. Quy trình phát triển phần mềm
Quy trình phát triển phần mềm được bắt đầu từ khi hình thành ý tưởng và
bao gồm nhiều vòng đời dưới dạng đường xoắn ốc. Quy trình này thể hiện sự hoàn
thiện dần từng giai đoạn của dòng sản phẩm theo thời gian. Mỗi vòng đời thường
bắt đầu từ công đoạn thiết kế, đặc tả các yêu cầu từ phía khách hàng đối với hệ
thống và kết thúc sau công đoạn kiểm định chấp nhận một phiên bản của sản phẩm.
Vòng đời tiếp theo là một bước phát triển để tạo ra một phiên bản mới của dòng sản
phẩm do công ty phần mềm đang bảo trì.
Quy trình phát triển phần mềm thường được thực hiện bởi thứ tự các thao tác:
Phân tích yêu cầu; Thiết kế sơ bộ; Thiết kế chi tiết; Lập trình và kiểm định đơn vị; Tích
hợp và kiểm định tích hợp; Kiểm định hệ thống; Khai thác và bảo trì hệ thống.
1.2.1. Các giai đoạn của quy trình phát triển phần mềm
Nhiều tổ chức phần mềm khác nhau có thể có các quy trình phát triển phần
mềm khác nhau; Tên gọi của mỗi giai đoạn phát triển cũng khác nhau. Nhưng hầu
hết mọi phần mềm đều được xây dựng theo thứ tự các giai đoạn như:
- Nghiên cứu sơ bộ (Preliminary Investigation);
- Phân tích hệ thống phần mềm (Analysis);
- Thiết kế hệ thống (Design of the System);
- Xây dựng phần mềm (Software Constrution);
- Thử nghiệm hệ thống (System Testing);
- Thực hiện, triển khai (System Implementation);
- Bảo trì, nâng cấp (System Maintenance).
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

7
1.2.1.1. Nghiên cứu sơ bộ
Trước khi bắt tay vào một dự án, cần tạo một bức tranh về ý tưởng. Ý tưởng
này phải nắm bắt các yêu cầu và xuất hiện trong giai đoạn khởi đầu. Các hoạt động

trong thời gian này thường bao gồm thu thập các ý tưởng, nhận biết rủi ro, nhận biết
các giao diện bên ngoài, các chức năng chính mà hệ thống cần cung cấp, và có thể
tạo một vài nguyên mẫu dùng để “chứng minh các khái niệm của hệ thống”. Ý
tưởng có thể đến từ nhiều nguồn khác nhau: Khách hàng, chuyên gia trong lĩnh vực
này, các nhà phát triển khác, chuyên gia về kỹ nghệ, các bản nghiên cứu tính khả thi
cũng như việc xem xét các hệ thống khác đang tồn tại. Một khía cạnh cần lưu ý là
code viết trong thời kỳ này thường sẽ bị “bỏ đi”, bởi chúng được viết nhằm mục
đích thẩm tra hay trợ giúp các giả thuyết khác nhau, chứ chưa phải code được viết
theo kết quả phân tích và thiết kế thấu đáo.
Giai đoạn này, nhóm phát triển hệ thống cần xem xét các yêu cầu của doanh
nghiệp (cần dùng hệ thống), những nguồn tài nguyên có thể sử dụng, công nghệ
cũng như cộng đồng người dùng cùng các ý tưởng của họ đối với hệ thống mới.
Ngoài ra người ta cũng tiến hành tạo một phiên bản thô của lịch trình và kế hoạch
sử dụng tài nguyên. Một giai đoạn nghiên cứu sơ bộ không được thực hiện sẽ dẫn
tới các hệ thống không được như mong muốn, tốn nhiều chi phí, bất khả thi và được
định nghĩa lầm lạc.
Kết quả của giai đoạn nghiên cứu sơ bộ là Báo cao kết quả nghiên cứu tính
khả thi. Khi hệ thống tương lai được chấp nhận dựa trên bản báo cáo này cũng là
lúc giai đoạn phân tích bắt đầu.
1.2.1.2. Phân tích hệ thống phần mềm
Đây được coi là giai đoạn quan trọng nhất trong công việc lập trình, người
thực hiện nó là nhà phân tích. Quá trình phân tích trả lời cho câu hỏi “Hệ thống cần
phải làm gì?”. Quá trình phân tích này bao gồm việc nghiên cứu chi tiết hệ thống,
tìm cho ra nguyên lý hoạt động của nó và những vị trí có thể được cải thiện hoặc
nâng cao hơn. Ngoài ra, phân tích còn là việc xem xét các chức năng mà hệ thống
cần cung cấp, các mối quan hệ giữa chúng, mối quan hệ bên trong với phía ngoài hệ
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

8
thống. Trong toàn bộ giai đoạn này, nhà phân tích và người dùng cần cộng tác mật

thiết với nhau để xác định các yêu cầu đối với hệ thống, tức là các tính năng mới
cần phải được đưa vào. Những mục tiêu cụ thể của giai đoạn này là:
- Xác định hệ thống cần phải làm gì.
- Nghiên cứu thấu đáo tất cả các chức năng cần cung cấp và những yếu tố
liên quan.
- Xây dựng mô hình nêu bật bản chất vấn đề từ một hướng nhìn có thực.
- Định nghĩa vấn đề cho chuyên gia lĩnh vực để nhận sự đánh giá, góp ý.
- Kết quả của giai đoạn này là bản Đặc tả yêu cầu (Requirements Specifications).
1.2.1.3. Thiết kế hệ thống
Sau giai đoạn phân tích, khi các yêu cầu cụ thể đối với hệ thống đã được xác
định, giai đoạn tiếp theo là thiết kế cho các yêu cầu mới. Việc thiết kế giải quyết
câu hỏi: Hệ thống làm cách nào để thỏa mãn các yếu cầu đã được nêu trong Đặc tả
yêu cầu. Trong giai đoạn thiết kế, các công việc thường được thực hiện là:
- Nhận biết form nhập liệu tùy theo các thành phần dữ liệu cần nhập;
- Nhận biết reports và những output mà hệ thống mới phải sản sinh;
- Thiết kế forms (vẽ trên giấy hay máy tính, sử dụng công cụ thiết kế);
- Nhận biết các thành phần dữ liệu và bảng tạo database;
- Ước tính các thủ tục giải thích quá trình xử lý từ input đến output.
Kết quả giai đoạn thiết kế là Đặc tả thiết kế (Design Specifications). Bản Đặc
tả thiết kế chi tiết sẽ được chuyển sang cho các lập trình viên để thực hiện giai đoạn
xây dựng phần mềm.
1.2.1.4. Xây dựng phần mềm
Đây là giai đoạn viết lệnh (code) thực sự tạo hệ thống. Từng người viết code
thực hiện những yêu cầu đã được nhà thiết kế định sẵn. Cũng chính người viết code
chịu trách nhiệm viết tài liệu liên quan đến chương trình, giải thích thủ tục
(procedure) do mình tạo nên được viết như thế nào và lý do cho việc này.
Để đảm bảo chương trình được viết nên phải thỏa mãn mọi yêu cầu có ghi
trước trong Bản đặc tả thiết kế chi tiết, người viết code cũng đồng thời phải tiến
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

9
hành thử nghiệm phần chương trình của mình. Phần thử nghiệm trong giai đoạn này
có thể được chia thành hai bước chính:
- Thử nghiệm đơn vị: Người viết code chạy thử các phần chương trình của
mình với dữ liệu giả (test/dummy). Việc này được thực hiện theo một kế hoạch thử,
cũng do chính người viết code soạn ra. Mục đích chính trong giai đoạn thử này là
xem chương trình có cho ra những kết quả mong đợi. Giai đoạn thử nghiệm đơn vị
nhiều khi được gọi là “Thử hộp trắng” (White Box Testing).
- Thử nghiệm đơn vị độc lập: Công việc này do một thành viên khác trong
nhóm đảm trách, thường chọn người không liên quan trực tiếp đến việc viết code
của đơn vị. Chương trình cần thử nghiệm để đảm bảo tính “độc lập”. Công việc thử
nghiệm này cũng được thực hiện dựa trên kế hoạch thử do người viết code soạn nên.
Kết quả của giai đoạn này là tài liệu về các mã nguồn của mỗi module cùng
với lời chú thích.
1.2.1.5. Thử nghiệm hệ thống
Sau khi các thủ tục đã được thử nghiệm riêng, cần phải thử nghiệm toàn bộ
hệ thống. Mọi thủ tục được tích hợp và chạy thử, kiểm tra xem mọi chi tiết ghi
trong Đặc tả yêu cầu và những mong chờ của người dùng có được thỏa mãn. Dữ
liệu thử cần được chọn lọc đặc biệt, kết quả cần được phân tích để phát hiện mọi
lệch lạc so với mong chờ.
Kết quả của giai đoạn Thử nghiệm hệ thống là các mã nguồn đã được hiệu
chỉnh cùng các chú thích. Kèm theo đó là tài liệu hướng dẫn sử dụng, cài đặt và vận
dụng chương trình, giải thích các cơ sở dữ liệu…
1.2.1.6. Thực hiện, triển khai
Trong giai đoạn này hệ thống vừa phát triển sẽ được triển khai. Trước khi để
người dùng thật sự bắt tay vào sử dụng hệ thống, nhóm các nhà phát triển cần tạo
các file dữ liệu cần thiết cũng như huấn luyện cho người dùng để đảm bảo hệ thống
được sử dụng hữu hiệu nhất.
1.2.1.7. Bảo trì, nâng cấp
Bảo trì và nâng cấp phần mềm là công việc trải qua nhiều thách thức nhất

trong quá trình phát triển phần mềm. Tùy theo các biến đổi trong môi trường sử
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

10
dụng, hệ thống có thể trở nên lỗi thời hay cần phải được sửa đổi nâng cấp để sử
dụng có hiệu quả. Hoạt động bảo trì hệ thống có thể rất khác biệt tùy theo mức độ
sử đổi và nâng cấp cần thiết.
Kết quả của của giai đoạn này là các ghi chép về các sửa đổi đã được thực
hiện cùng các lý do.
1.2.2. Các mô hình vòng đời phần mềm
Vòng đời phần mềm (SLC - Software Life Cycle) là thời kỳ tính từ khi phần
mềm được đề xuất sử dụng cho đến khi bị loại bỏ (tức là hình thành đáp ứng yêu
cầu vận hành, bảo trì, cho đến khi loại bỏ không đâu dùng nữa).
Mô hình vòng đời phần mềm là tập hợp các công việc và quan hệ giữa chúng
với nhau diễn ra trong quá trình phát triển phần mềm.
Vòng đời phần mềm được chia thành các pha chính như: Xác định yêu cầu,
triển khai, kiểm thử, bảo trì (vận hành)… Phạm vi thứ tự các pha khác nhau tùy
theo từng mô hình dự án cụ thể.
Vòng đời phần mềm của mỗi sản phẩm nhiều khi có sự khác biệt rất lớn. Có
sản phẩm được thiết kế và viết chương trình rất nhanh nhưng lại tốn hàng năm để
bảo trì do phải sửa đổi chương trình cho phù hợp với các yêu cầu của khách hàng.
Cũng có những sản phẩm phần mềm sau một thời gian sử dụng người ta nhận thấy
rằng có lẽ nên viết hẳn một sản phẩm mới hoàn toàn thì sẽ tốt hơn là bảo trì sản
phẩm cũ. Có nhiều mô hình khác nhau, một số trong đó được ứng dụng khá phổ
biến trên thế giới.
1.2.2.1. Mô hình tăng trưởng (growth model)
Một phần mềm ra đời được đưa vào sử dụng, trong quá trình sử dụng ngoài
việc phát triển và sửa chữa những sai sót, người ta thấy cần nâng cấp chất lượng
bằng cách cải tiến một vài thuật toán hoặc thêm một số chức năng… Mỗi lần nâng
cấp như vậy người ta lại dựa trên nền tảng phần mềm đã có và xem xét, sửa đổi lại

tài liệu các pha.
Trong mô hình tăng trưởng, người ta xem phần mềm bao gồm nhiều thành
phần (build) tương đối độc lập nhau. Mỗi thành phần được coi như một phần mềm
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

11
nhỏ, được thiết kế, lập trình, kiểm thử và đưa cho khách hàng sử dụng theo mô hình
thác đổ rồi kết hợp dần thành phần mềm hoàn chỉnh thỏa mãn tất cả các yêu cầu của
khách hàng. Thay vì xây dựng phần mềm hoàn chỉnh, người ta xây dựng các phần
mềm con rồi tích hợp dần cho tới khi đạt được sản phẩm mong muốn.
Ưu điểm của mô hình này là phần đầu tiên chứa đựng những đặc trưng quan
trọng nhất được nhanh chóng xây dựng và chuyển giao cho khách hàng sử dụng.
Thời gian làm phần đầu tiên này thường rất ngắn so với thời gian xây dựng toàn bộ
phần mềm hoàn chỉnh. Như vậy khách hàng được sử dụng sản phẩm trong thời gian
ngắn nhất và họ có thể được hưởng lợi từ việc sử dụng phần mềm. Nhờ theo sát
từng bước phát triển của phần mềm mà khách hàng có những ý kiến xác đáng, giúp
cho nhà phát triển đi đúng hướng và sản phẩm cuối cùng sẽ thỏa mãn được các yêu
cầu đặt ra.
Tuy nhiên, khó khăn trong việc sử dụng mô hình tăng trưởng chính là sự
tích hợp phần mới phát triển với phần chương trình đã có, vì thế thiết kế phải có
tính mở và tính mềm dẻo để thích nghi với việc mở rộng dần. Sự điều khiển toàn
bộ quy trình phát triển phần mềm có thể bị mất và sản phẩm nhận được thay vì có
tính mở lại là khó khăn cho những người bảo trì. Nếu không có những nhà chuyên
môn trình độ cao thì sản phẩm phát triển theo mô hình này có thể trở thành sản
phẩm kém chất lượng.
Nếu phần mềm có thể phân chia thành những thành phần tương đối độc lập
nhau thì có thể áp dụng mô hình này. Với những bài toán như xây dựng phần mềm
Quản lý dịch vụ bay ở các công ty hàng không; Chương trình Quản lý tín dụng ngân
hàng, Quản lý trường học… Tính liên kết giữa các phần khá cao thì không nên áp
dụng mô hình này.

1.2.2.2. Mô hình đồng bộ và ổn định (Synchronize-And-Stabilize Model)
Trong mô hình này, pha xác định yêu cầu được thực hiện bằng cách phỏng
vấn rất nhiều khách hàng dự kiến. Các đặc trưng của nhu cầu khách hàng được liệt
kê theo thứ tự ưu tiên, sau đó tài liệu đặc tả được soạn thảo. Tiếp theo, công việc
được chia làm ba hoặc bốn phần. Phần thứ nhất chứa các đặc trưng quan trọng nhất,
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

12
phần thứ hai chứa các đặc trưng quan trọng thứ hai… Mỗi thành phần sẽ được xây
dựng bởi một số nhóm nhỏ làm việc song song. Cuối mỗi ngày, các nhóm đồng bộ
hóa (Synchronize), tức là họ hợp lại các phần họ đã làm riêng biệt thành một phần
đồng nhất, sau đó họ kiểm tra, sửa lỗi và kiểm thử. Sự ổn định hóa (stabilize) được
thực hiện ở giai đoạn cuối của mỗi phần. Trong giai đoạn này những lỗi còn sót lại
được phát hiện, được sửa chữa và thành phần được đóng gói (frozen), tức là không
thực hiện thay đổi nào đối với đặc tả.
Các bước đồng bộ hóa được lặp lại bảo đảm rằng các thành phần khác nhau
có thể được kết hợp và cùng làm việc tốt. Một điểm lợi của cách làm này là những
người phát triển có thể sớm nhìn thấy sự hoạt động của phần mềm và có thể hiệu
chỉnh các yêu cầu ngay trong quá trình các thành phần được xây dựng. Mô hình này
có thể áp dụng ngay cả trong trường hợp các đặc tả ban đầu không hoàn thiện.
1.2.2.3. Mô hình hướng đối tượng (Object-Oriented model)
Trong mô hình hướng đối tượng, tính lặp giữa các pha và giữa các phần
trong một pha xảy ra nhiều hơn so với mô hình khác. Một trong những mô hình
giống như mô hình hướng đối tượng là mô hình núi đồi, nó được biểu diễn bằng các
hình tròn có một phần chồng lên nhau. Bên trong các vòng tròn có các mũi tên uốn
cong ngụ ý nói rằng trong mỗi pha cũng có tính lặp giữa các phần. Các pha có phần
chung là:
- Pha yêu cầu và pha phân tích hướng đối tượng.
- Pha thiết kế hướng đối tượng, pha lập trình và tích hợp.
- Pha sử dụng và bảo trì.

Kết luận: Có rất nhiều mô hình vòng đời phần mềm, tuy nhiên các mô hình nói
chung có những thành phần tương tự nhau, chúng chỉ khác nhau ở trình tự tổ hợp, lắp
ghép các thành phần. Điểm khác biệt nổi trội giữa các mô hình là các vòng lặp thể
hiện quy trình làm mịn tại các pha của quy trình.
1.3. Chất lƣợng phần mềm
Như đã nêu ở phần mở đầu, chất lượng phần mềm có nhiều cách định nghĩa
khác nhau tùy theo cách nhìn của mỗi đối tượng người dùng. Từ cách nhìn của
khách hàng, chất lượng được xác định là việc đáp ứng nhu cầu và đạt tới sự thỏa
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

13
mãn; Từ cách nhìn của người phát triển, phần mềm được thiết kế tốt và sản phẩm
tuân thủ theo thiết kế đó (đáp ứng yêu cầu đặc tả chức năng); Theo Nguyễn Thiện
Luận - “Giáo trình đo lường phần mềm” - Chất lượng là một tập hợp các tính chất
và đặc trưng của sản phẩm tạo ra cho nó khả năng thỏa mãn nhu cầu đã được nêu ra
hoặc còn tiềm ẩn. Tôi chắc rằng còn nhiều định nghĩa về chất lượng phần mềm hơn
nữa. Sự mới mẻ trong quan niệm về chất lượng phần mềm chính là độ tin cậy đối
với phần mềm đó. Khi người sử dụng thỏa mãn với sản phẩm tức là khi nhu cầu
được đáp ứng, và phần mềm có độ tin cậy cao thì đó là một phần mềm tốt.
Những năm cuối thế kỷ XX, tổ chức ISO đã tập trung nghiên cứu rất nhiều
vào vấn đề tiêu chuẩn chất lượng phần mềm. Cách tiếp cận về các tiêu chí đánh giá
chất lượng phần mềm của ISO càng được quan tâm và áp dụng nhiều hơn. Kết quả
của sự tập trung này là một loạt các bộ tiêu chuẩn nhằm hướng tới chất lượng toàn
diện trong suốt vòng đời của sản phẩm phần mềm từ khi phôi thai cho tới lúc lạc
hậu cần thay thế. Theo cách tiếp cận của ISO, chất lượng toàn diện của phần mềm
cần phải được quan tâm từ chất lượng quy trình tới chất lượng sản phẩm nội bộ.
Chất lượng sản phẩm đối sánh với yêu cầu của người dùng (chất lượng hướng ngoại)
và chất lượng phần mềm trong sử dụng.
Chất lượng phần mềm đóng vai trò vô cùng quan trọng trong ngành Công
nghiệp phần mềm. Để đảm bảo phần mềm khi ra đời thỏa mãn được nhu cầu của

khách hàng, các sản phẩm phần mềm đang gặp phải thách thức mới, đó là vấn đề
chất lượng. Điều này có nghĩa là sản phẩm phần mềm khi ra đời phải đạt được sự
thỏa mãn, hoàn thiện, chuyên nghiệp và luôn đổi mới để đáp ứng được các yêu cầu
khắt khe của người dùng. Vậy phần mềm có đáp ứng được các đòi hỏi đó hay
không cần phải có hoạt động đánh giá cụ thể.
1.4. Đánh giá phần mềm
Đánh giá phần mềm là một phương pháp đo, tức là nó xác định giá trị của
nguyên mẫu. Kết quả của phép đo trả lời cho câu hỏi: Trong hai cái cái nào tốt hơn?
Mức độ tốt? Có nhiều phương pháp đo do các tổ chức, các nhóm nghiên cứu đề
xuất. Tuy nhiên hiện nay chưa có một chuẩn đo phần mềm nào được chấp nhận
rộng rãi trên toàn thế giới.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

14
1.4.1. Tầ m quan trọ ng của việc đánh giá chấ t lượ ng phần mềm
Như đã nói, chất lượng phần mềm đóng vai trò vô cùng quan trọng trong
ngành Công nghiệp phần mềm. Một sai lầm dù rất nhỏ của phần mềm cũng có thể
gây ra hậu quả nghiêm trọng. Các nhược điểm trong phần mềm không chỉ gây phiền
phức cho người dùng mà còn gây tổn thất rất lớn cho nền kinh tế. Chúng ta đã
chứng kiến sự cố máy tính Y2K hơn 10 năm về trước (năm 2000). Từ một giải pháp
tiết kiệm bộ nhớ (chỉ dùng hai chữ số cuối để biểu diễn năm thay vì bốn chữ số) vào
đầu những năm 70 của thế kỷ trước dẫn đến việc 25 năm sau người ta phải bỏ ra
nhiều tỷ dollars để khắc phục sự cố này.
Ở nước Mỹ ước tính hàng năm thiệt hại do nhược điểm trong phần mềm gây
ra lên đến 59,5 tỷ USD - Theo số liệu của Viện Công Nghệ và Tiêu Chuẩn Quốc
Gia (NIST) thuộc Bộ Thương Mại Mỹ. Và cũng theo NIST, thử nghiệm để phát
hiện và loại bỏ khiếm khuyết ngay từ quá trình sản xuất phần mềm có thể giảm mức
thiệt hại khoảng 22,2 tỷ USD trong tổng số 59,5 tỷ này. Nhiều doanh nghiệp đã
nhận thức đúng về vai trò của chất lượng phần mềm và định hướng xây dựng các
quy trình sản xuất phần mềm theo chuẩn quốc tế với mục đích sản xuất phần mềm

chất lượng.
Ngày nay vấn đề đánh giá chất lượng sản phẩm phần mềm là một trong
những vấn đề nòng cốt trong việc phát triển Công nghiệp phần mềm. Nó đã được
quan tâm không chỉ từ các quốc gia muốn phát triển Công nghiệp phần mềm, mà
còn từ rất nhiều các tổ chức, trung tâm, Viện nghiên cứu của một ngành nghiên cứu
khoa học về Công nghệ phần mềm.
Để đánh giá được chất lượng phần mềm có đáp ứng được nhu cầu cho trước
hay không thì cần phải đưa các tiêu chí đánh giá chấ t lượ ng ph ần mềm về một tiêu
chuẩn chung và phải đánh giá chấ t lượ ng phần mềm trong thực tế (tức là phầ n mề m
phải qua sử dụng). Hiện nay ở Việt Nam đã có một số tổ chức độc lập xây dựng các
tiêu chí đánh giá chất lượng phần mềm như:
- Hiệp hội Doanh nghiệp Phần mềm Việt Nam (VINASA): Hiệp hội này đã
thành lập Ban Công tác chất lượng VINASA (VINASA QUALITY COMMITEE -
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

15
VQC). Với nhiệm vụ xây dựng “Các tiêu chuẩn và đánh giá chất lượng phần mềm
Việt Nam”, tư vấn cho các doanh nghiệp phần mềm về quy trình đảm bảo chất
lượng phần mềm, cung cấp cho doanh nghiệp các chỉ tiêu, các tiêu chuẩn để đánh
giá chất lượng phần mềm trong các lĩnh vực khác nhau dựa trên các chuẩn quốc tế
ISO-9000, ISO-9126, ISO-14598…
- Công ty cổ phần phần mềm Hà Nội (HanoiSoftware): Kinh doanh trên các
giải pháp phần mềm cho Website thương mại điện tử, phát triển và triển khai các
cổng thông tin tích hợp. Xây dựng các sản phẩm phần mềm đáp ứng các mô hình
chất lượng của tiêu chuẩn ISO-9126.
- Tập đoàn Bưu chính Viễn thông Việt Nam: Thực hiện đánh giá sản phẩm
phần mềm theo tiêu chuẩn ISO/IEC 12119: 1994 về “Yêu cầu và kiểm tra chất
lượng phần mềm”. Các tiêu chí đánh giá về phần mềm của Trung tâm Công nghệ
thông tin CDiT thuộc Học viện Bưu chính Viễn thông được xây dựng dựa trên 6
đặc tính chất lượng nêu trong tiêu chuẩn ISO/IEC 9126 và áp dụng tiêu chuẩn

ISO/IEC 12119:1994 để đánh giá chung cho các tài liệu hướng dẫn, tài liệu mô tả
sản phẩm, chương trình và dữ liệu.
Tóm lại, mỗi một tổ chức áp dụng đánh giá phần mềm một cách riêng theo
đặc thù của tổ chức đó. Ở Việt Nam hiện nay vẫn chưa có một tiêu chuẩn chung nào
để đánh giá chất lượng phần mềm, chưa thể trả lời được câu hỏi đánh giá phần mềm
trong nước theo các mặt nào, sử dụng tiêu chuẩn nào, bằng cách nào đánh giá được
thực chất chất lượng phần mềm, độ tin cậy và chính xác của các phương pháp đánh
giá. Để đánh giá chất lượng của sản phẩm phần mềm có đáp ứng được các nhu cầu
cho trước hay không thì cần áp dụng tiêu chuẩn và tiêu chí đánh giá cụ thể, có tiến
trình đánh giá phù hợp.
1.4.2. Một số mô hình đánh giá chất lượng phần mềm
1.4.2.1. Mô hình ISO/IEC-9126 [5]
ISO-9126 là bộ tiêu chuẩn quốc tế về Đánh giá phần mềm, được chia làm
bốn phần:
 9126-1 Đưa ra mô hình chất lượng sản phẩm phần mềm.
 9126-2 Độ đo ngoài.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

16
 9126-3 Độ đo trong.
 9126-4 Độ đo cho chất lượng sản phẩm phần mềm trong quá trình sử dụng.
Mô hình chất lượng ISO-9126 trên thực tế được mô tả là một phương pháp
phân loại và chia nhỏ những thuộc tính chất lượng, nhằm tạo nên những đại lượng
đo đếm được dùng để kiểm định chất lượng của sản phẩm phần mềm. Dưới đây đưa
ra 6 tiêu chuẩn để đánh giá chất lượng sản phẩm phần mềm trong mô hình chất
lượng ISO/IEC 9126-1.
- Tiêu chuẩn 1. Tính chức năng (functionality): Khả năng của phần mềm
cung cấp các chức năng đáp ứng được các yêu cầu khi nó được sử dụng với những
điều kiện cụ thể. Tiêu chuẩn này là tổ hợp của các thuộc tính chất lượng:
+ Tính thích hợp (suitability): Phần mềm cung cấp một tập các chức năng thích

hợp cho một công việc cụ thể cũng như cho những mục tiêu của người sử dụng.
+ Tính chính xác (accuracy): Phần mềm có thể cung cấp các kết quả chính xác.
+ Tính tương tác (interoperability): Khả năng tương tác với các hệ thống khác.
+ Tính chấp hành (compliance): Phần mềm có thể tuân theo các tiêu chuẩn,
những quy ước hoặc những điều chỉnh trong pháp luật.
+ Tính an ninh - An toàn (security): Phần mềm có thể ngăn ngừa sự truy
nhập trái phép, bảo vệ được các thông tin bảo mật.
- Tiêu chuẩn 2. Ổn định và tin cậy (reliability): Phần mềm duy trì hiệu suất
hoạt động của hệ thống khi sử dụng dưới những điều kiện xác định.
+ Tính chắc chắn (maturity): Tránh được sự hỏng hóc như kết quả của
những lỗi trong phần mềm.
+ Tính tha thứ lỗi (fault tolerance): Phần mềm duy trì hiệu suất hoạt động
trong những trường hợp xảy ra lỗi phần mềm hoặc sự xâm phạm giao diện của nó.
+ Tính khôi phục (recoverability): Phần mềm thực hiện và khôi phục dữ liệu
trong trường hợp xảy ra lỗi.
+ Tính sẵn sàng (availability): Phần mềm có thể ở trong trạng thái dễ thực hiện
một chức năng tại một thời điểm với những điều kiện xác định của việc sử dụng.
- Tiêu chuẩn 3. Dễ sử dụng (usability): Phần mềm có thể hiểu được, học
được, sử dụng được và hấp dẫn người sử dụng.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

17
+ Có thể hiểu được (understandability): Giúp cho người dùng xác định được
liệu phần mềm có thích hợp hay không và cách sử dụng nó trong các công việc cụ thể.
+ Có thể học tập - Nghiên cứu (learnability): Cho phép người dùng nhanh
chóng thu được các kiến thức thông qua việc sử dụng phần mềm trong công việc
của họ.
+ Dễ thao tác (operability): Người dùng có thể thao tác và điều khiển phần mềm.
- Tiêu chuẩn 4. Hiệu quả (efficiency): Phần mềm cung cấp một hiệu suất
tương đối trong việc sử dụng tài nguyên hệ thống.

+ Hiệu quả về thời gian (time behaviour): Thời gian xử lý, thời gian phúc
đáp của hệ thống và lưu lượng công việc.
+ Hiệu quả về tài nguyên (resource utilisation): Sử dụng tài nguyên thích
hợp trong một khoảng thời gian hợp lý.
- Tiêu chuẩn 5. Cập nhật - Bảo trì (maintainability): Phần mềm có thể sửa
đổi được.
+ Phân tích được (analysability): Phần mềm có thể chuẩn đoán những sự
thiếu sót hoặc những nguyên nhân gây lỗi trong phần mềm, hoặc những phần sẽ
được sửa đổi trong tương lai được xác định.
+ Thay đổi được (changeability): Phần mềm cho phép một sự cải tiến xác
định sẽ được thực hiện.
+ Ổn định (stability): Phần mềm giảm thiểu các hiện tượng bất ngờ từ những
nâng cấp của phần mềm.
+ Có thể kiểm tra (testability): Cho phép kiểm tra sau khi thay đổi và nâng cấp.
- Tiêu chuẩn 6. Linh hoạt (portability): Phần mềm sẽ được chuyển từ môi
trường này sang môi trường khác.
+ Tính thích nghi (adaptability): Phần mềm có thể được thay đổi cho phù
hợp với các môi trường khác nhau.
+ Cài đặt được (installability): Có thể cài đặt trên một môi trường cụ thể.
+ Cùng tồn tại (co-existence): Có thể tồn tại cùng với các phần mềm khác
trong một môi trường chia sẻ tài nguyên.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên