Đánh giá tính khả dụng của cổng thông tin chính phủ điện tử việt nam

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN THỊ VÓC

ĐÁNH GIÁ TÍNH KHẢ DỤNG CỦA CỔNG
THÔNG TIN CHÍNH PHỦ ĐIỆN TỬ VIỆT NAM
Ngành: Công nghệ thông tin
Chuyên ngành: Kỹ thuật phần mềm
Mã số: 60.48.10.03

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. Trương Anh Hoàng

HÀ NỘI – 2015


LỜI CAM ĐOAN
Tôi xin cam đoan nội dung của luận văn “Đánh giá tính khả dụng của cổng thông tin
chính phủ điện tử Việt Nam” là sản phẩm do tôi thực hiện dưới sự hướng dẫn của
PGS.TS Trương Anh Hoàng. Trong toàn bộ nội dung của luận văn, những điều được
trình bày hoặc là của cá nhân hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các
tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp.
Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy định cho lời
cam đoan của mình.

Hà Nội, ngày tháng

năm 2015

Người cam đoan

Trần Thị Vóc


LỜI CẢM ƠN
Trước tiên tôi xin được bày tỏ sự trân trọng và lòng biết ơn sâu sắc đối với PGS.TS.
Trương Anh Hoàng - Giảng viên Bộ môn Công nghệ phần mềm - Khoa Công nghệ
thông tin - Trường Đại học Công nghệ - ĐHQGHN. Trong thời gian học và làm luận
văn tốt nghiệp, thầy đã dành nhiều thời gian quí báu và tận tình chỉ bảo, hướng dẫn tôi
trong việc nghiên cứu, thực hiện luận văn.
Tôi xin được cảm ơn các Thầy/Cô ở Khoa Công nghệ thông tin – Trường Đại học Công
nghệ đã giảng dạy chúng tôi trong quá trình học tập và góp ý cho tôi hoàn thiện trong
quá trình làm luận văn.
Xin cảm ơn các bạn bè, đồng nghiệp và đặc biệt là các thành viên trong gia đình đã tạo
mọi điều kiện tốt nhất, động viên tôi trong suốt quá trình học tập và nghiên cứu để hoàn
thành tốt bản luận văn tốt nghiệp này.
Mặc dù đã cố gắng hoàn thiện luận văn với tất cả sự nỗ lực của bản thân, nhưng chắc
chắn không thể tránh khỏi những thiếu sót, tôi rất mong sự góp ý của bạn bè, thầy cô và
những người quan tâm tới đề tài này.

Hà Nội, ngày

tháng năm 2015

Trần Thị Vóc

5

MỤC LỤC
Chương 1! Tổng quan .................................................................................................. 9!
1.1!

Đặt vấn đề ...................................................................................................... 9!

1.2!

Tổng quan về tính khả dụng của hệ thống ..................................................... 9!

1.2.1! Định nghĩa .................................................................................................. 9!
1.2.2! Các hoạt động đánh giá tính dễ sử dụng của hệ thống............................. 10!
1.3!

Phân loại các phương pháp đánh giá khả năng sử dụng .............................. 10!

1.4!

Phạm vi nghiên cứu của đề tài ..................................................................... 11!

Chương 2! Phương pháp kiểm duyệt để đánh giá tính khả dụng của hệ thống ......... 13!
2.1!

Phương pháp kiểm duyệt ............................................................................. 13!

2.2!

Các hoạt động của quá trình kiểm duyệt ...................................................... 13!

2.2.1! Xác định các vấn đề liên quan đến tín khả dụng...................................... 13!

2.2.2! Chu trình đánh giá tính khả dụng ............................................................. 14!
2.2.3! Đào tạo và xây dựng đội thiết kế ............................................................. 14!
2.3!

Các phương pháp kiểm duyệt ...................................................................... 14!

2.3.1! Phương pháp đánh giá dựa trên kinh nghiệm .......................................... 17!
2.3.2! Phương pháp đánh giá thăm dò................................................................ 25!
2.3.3! Hiệu quả của phương pháp kiểm duyệt ................................................... 31!
2.3.4! Khi nào thì sử dụng các phương pháp kiểm tra ....................................... 32!
Chương 3! Đánh giá tính khả dụng của hệ thống cổng thông tin chính phủ điện tử Việt
Nam
34!
3.1!

Giới thiệu cổng thông tin chính phủ điện tử Việt Nam ............................... 34!

3.2!

Đánh giá tính dễ khả dụng cổng thông tin chính phủ điện tử ...................... 34!

3.2.1! Đánh giá dựa trên kinh nghiệm ................................................................ 34!
3.2.2! Đánh giá sử dụng phương pháp thăm dò ................................................. 40!
3.3!

Đề xuất cải tiến giao diện cho cổng thông tin điện tử chính phủ................. 44!

3.3.1! Tóm tắt các vấn đề hiện tại ...................................................................... 44!

4

3.3.2! Thiết kế lại hệ thống ................................................................................ 45!
Chương 4! Kết luận .................................................................................................... 59!
4.1!

Kết quả nghiên cứu ...................................................................................... 59!

4.2!

Hướng phát triển .......................................................................................... 59!

5


DANH MỤC HÌNH ẢNH
Hình 1: Mối liên quan giữa lỗi khả dụng tìm thấy với tập người đánh giá [6] ........... 18!
Hình 2: Tỉ trọng lỗi khả dụng trên số người đánh giá [6] ............................................ 22!
Hình 3: Thiết kế bố cục trang chủ ................................................................................ 49!
Hình 5: Thiết kế bố cục trang "Dịch vụ công"............................................................. 51!
Hình 6: Thiết kế bố cục trang "Hệ thống văn bản" ...................................................... 53!
Hình 7: Thiết kế bố cục trang "Thông tin đa phương tiện" ......................................... 54!
Hình 8: Thiết kế bố cục trang tin chi tiết có nội dung dài ........................................... 56!
Hình 9: Thiết kế bố cục trang "Trợ giúp" .................................................................... 57!
Hình 10: Thiết kế bố cục trang "Báo lỗi" .................................................................... 58!

6


DANH MỤC BẢNG BIỂU

Bảng 1: Kết quả đánh giá tính khả dụng dựa trên kinh nghiệm .................................. 40!
Bảng 2: Đánh giá tính khả dụng bằng phương pháp thăm dò...................................... 44!
Bảng 3: Thiết kế lại cấu trúc trang web ....................................................................... 47!

7


MỞ ĐẦU
Xuất phát từ tình hình phát triển và tầm quan trọng của hệ thống cổng thông tin chính
phủ điện tử Việt Nam, xuất phát từ chủ trương tin học hóa hệ thống quản lý của chính
phủ, xuất phát từ nhu cầu tương tác nhanh chóng và hiệu quả giữa người dân và chính
phủ nhằm tiết kiệm chí phí về thời gian và chi phí về quản lý. Luận văn thực hiện một
cuộc khảo sát các phương pháp đánh giá tính khả dụng và lựa chọn phương pháp phù
hợp với tình hình phát triển để đánh giá tính khả dụng của cổng thông tin điện tử chính
phủ.
Nội dung của luận văn gồm 3 chương chính:
Chương 1: Trình bày tổng quan về các phương pháp đánh giá tính khả dụng.
Chương 2: Trình bày chi tiết về phương pháp kiểm duyệt đánh giá tính khả dụng của hệ
thống, trong đó tập trung mô tả hai phương pháp chính là đánh giá dựa trên kinh nghiệm
và đánh giá thăm dò.
Chương 3: Áp dụng hai phương pháp trên vào đánh giá tính khả dụng của cổng thông
tin chính phủ điện tử Việt Nam. Dựa trên kết quả đánh giá luận văn đề xuất một số cải
tiến nhằm giảm thiểu các vấn đề về tính khả dụng của hệ thống.

8


Chương 1! Tổng quan
1.1! Đặt vấn đề
Tính khả dụng [9] là mức độ mà một hệ thống máy tính cho phép người dùng trong một

bối cảnh sử dụng cụ thể có thể đạt được những mục tiêu nhất định với cảm giác hài
lòng.
Đánh giá tính khả dụng (tính dễ sử dụng) là một phần quan trọng của quá trình thiết kế
giao diện người dùng. Đánh giá tính khả dụng bao gồm các phương pháp để đo lường
các khía cạnh của khả năng sử dụng giao diện người dùng hệ thống. Tuy nhiên, việc
đánh giá có thể tốn kém về thời gian và nguồn lực con người, do đó cần lựa chọn phương
pháp để đánh giá khả năng sử dụng phù hợp với đặc trưng của hệ thống sao cho tiết
kiệm chi phí về thời gian, nguồn lực, con người.

1.2! Tổng quan về tính khả dụng của hệ thống
1.2.1! Định nghĩa
Tính khả dụng [5] là một thuộc tính chất lượng của hệ hống thể hiện ở mức độ dễ sử
dụng khi con người tương tác với giao diện hệ thống. Tính khả dụng bao gồm tính dễ
sử dụng, tính hiệu quả và cuối cùng là sự hài lòng của người dùng cuối.
Tính khả dụng không phải là một thuộc tính đơn lẻ, nó bao gồm một tập hợp các thuộc
tính:
o! Thiết kế trực quan: Người dùng gần như không mất thời gian để tìm hiểu kiến
trúc của hệ thống. Để đảm bảo tính chất này hệ thống cần được thiết kế trực
quan, nhìn vào người dùng có thể hiểu ngay để thực hiện nhiệm vụ của mình
họ cần phải đi đến đâu và làm gì.
o! Tính dễ học: tốc độ nhanh chóng mà một người dùng có thể hoàn thành các
nhiệm vụ cơ bản cho dù họ chưa từng thấy giao diện hệ thống trước đó
o! Hiệu quả của việc sử dụng: tốc độ nhanh chóng mà một người dùng có kinh
nghiệm có thể hoàn thành các nhiệm vụ.
o! Tính dễ nhớ: sau khi xem hệ thống, người dùng có thể nhớ đủ để sử dụng hiệu
quả ở lần xem tiếp theo.
o! Khả năng chống lỗi và bảo mật: Mức độ thường xuyên mà người dùng gây ra
lỗi khi sử dụng hệ thống, mức độ nghiêm trọng của lỗi và cách người dùng
quay lại trạng thái trước lỗi.
o! Mức độ hài lòng của người dùng đối với hệ thống.

9


1.2.2! Các hoạt động đánh giá tính dễ sử dụng của hệ thống
Đánh giá khả năng sử dụng bao gồm một chuỗi các hoạt động như sau:
o! Capture: Thu thập dữ liệu về khả năng sử dụng, ví dụ: Thời gian hoàn thành
nhiệm vụ, các sai sót, vi phạm nguyên tắc, các đánh giá chủ quan.
o! Analysis: Phân tích, diễn giải dữ liệu khả năng sử dụng để xác định các vấn đề
về khả năng sử dụng trong giao diện hệ thống.
o! Critique (Phê bình): đề xuất giải pháp hoặc đưa ra các cải tiến để giảm thiểu các
vấn đề.

1.3! Phân loại các phương pháp đánh giá khả năng sử dụng
Dựa theo phân loại của Balbo [9] chúng ta có năm lớp phương thức đánh giá khả năng
sử dụng dưới đây:
Kiểm thử (Testing): phương pháp này yêu cầu các ứng viên tham gia một cuộc kiểm
thử. Người dùng sẽ thao tác một số nhiệm vụ đã xác định trước. Dựa vào kết quả công
việc để xác định các vấn đề về khả năng sử dụng của hệ thống. Phương pháp đánh giá
khả năng sử dụng này yêu cầu việc ghi nhận các hành động của người dùng khi họ thao
tác với hệ thống. Điều này có thể thực hiện bởi một người đánh giá bằng cách trực tiếp
xem cách người dùng thao tác với hệ thống và ghi lại. hoặc cũng có thể bằng cách xem
đoạn phim về phiên làm việc.
Kiểm duyệt (Inspection): Một quá trình kiểm duyệt về tính khả dụng là phương pháp
đánh giá theo đó một người đánh giá sẽ xem xét các khía cạnh khả dụng của một thiết
kế giao diện người dùng xem có phù hợp với một tập các hướng dẫn không. Các hướng
dẫn có thể là các quy định rất cụ thể dựa trên các nguyên tắc chung. Không giống như
các phương pháp đánh giá tính khả dụng khác, phương pháp kiểm duyệt dựa trên phán
đoán của người đánh giá. Suốt quá trình xem xét, người đánh giá cố gắng để mô phỏng
quá trình giải quyết vấn đề của người dùng khi họ thực hiện các nhiệm vụ trên giao diện

cụ thể. Tại mỗi bước của một nhiệm vụ, người kiểm tra đánh giá xem người sử dụng sẽ
thực hiện bước đó hoàn thành hay thất bại. Từ đó, người đánh giá có thể đưa ra một tài
liệu đầy đủ về quá trình phân tích.
Điều tra (Inquiry): Tương tự như các cách tiếp cận kiểm tra tính khả dụng, các phương
pháp điều tra yêu cầu phản hồi từ người dùng và thường được sử dụng trong quá trình
kiểm tra tính khả dụng. Tuy nhiên, trọng tâm không phải là việc nghiên cứu các nhiệm
vụ cụ thể hoặc đo lường hiệu quả. Thay vào đó, mục tiêu của các phương pháp này là
thu thập những cảm nhận chủ quan (tức là, sở thích hay ý kiến) về các khía cạnh khác
nhau của một giao diện người dùng. Người đánh giá cũng sử dụng phương pháp điều

10


tra, chẳng hạn như khảo sát, bảng câu hỏi và phỏng vấn, thu thập dữ liệu bổ sung sau
khi một hệ thống được đưa vào sử dụng; điều này là hữu ích cho việc cải thiện giao diện
cho phiên bản tương lai. Ngoài ra, người đánh giá sử dụng phương pháp điều tra để
đánh giá nhu cầu sớm trong quá trình thiết kế. Các phương pháp điều tra thay đổi tùy
theo việc người đánh giá tương tác với một người dùng hoặc một nhóm người sử dụng
hay người dùng báo cáo các trải nghiệm của họ bằng cách sử dụng bảng câu hỏi hoặc
logs sử dụng, có thể kết hợp với ảnh chụp màn hình.
Mô hình phân tích (Analytical modeling): tức là đánh giá hệ thống dựa trên mô hình
của giao diện thiết kế qua đó tao ra các dự đoán về khả năng sử dụng. Phương pháp này
bổ sung các kỹ thuật đánh giá cho phương pháp Testing. Với một số đại diện hoặc mô
hình của giao diện người dùng và/hoặc người sử dụng, các phương pháp này cho phép
người đánh giá dự đoán khả năng sử dụng một cách không tốn kém.
Mô phỏng (Simulatio): mô phỏng tương tác của người dùng với giao diện, sau đó lấy
kết quả của quá trình tương tác (hiệu năng sử dụng, các lỗi). Phương pháp này bổ trợ
cho phương pháp Analytical modeling. Giả lập bổ sung cho các phương pháp truyền
thống, và cũng giống như mô hình hóa phân tích, có thể được xem như là vốn dĩ đã hỗ
trợ phân tích tự động. Sử dụng các mô hình của người dùng hoặc giao diện người dùng,

các cách tiếp cận này giả lập tương tác của người dùng và báo cáo kết quả tương tác
này, ví dụ theo dạng biểu mẫu báo cáo đo lường hiệu năng hoặc báo cáo thao tác trên
giao diện. Người đánh giá có thể chạy giả lập với nhiều tham số khác nhau để tìm hiểu
cách cân bằng các thành phần trên giao diện người dùng, từ đó lựa chọn cách thể hiện
tối ưu nhất. Giả lập cũng được dùng để tự động sinh ra dữ liệu hành vi tổng hợp để phân
tích dữ liệu với các kĩ thuật phân tích nhật ký sử dụng (log), hoặc phát lại sự kiện trên
giao diện. Vì thế, giả lập có thể xem, ở khía cạnh nào đó, như là hỗ trợ bắt sự kiện tự
động.
Các phương pháp đánh giá tính khả dụng trong lớp phương thức testing, inspection và
inquiry phù hợp với việc xách định các vấn đề khả năng sử dụng cụ thể qua đó ta đánh
giá tổng kết chung về khả năng sử dụng. Các phương thức Analytical modeling và
Simulation là các kỹ thuật đánh giá tính khả dụng cho phép người đánh giá dự đoán khả
năng sử dụng của người dùng và các mô hình giao diện. Các công nghệ phần mềm được
sử dụng trong thực tế có ảnh hưởng lớn đến ba phương pháp đầu tiên. Ngược lại hai kỹ
thuật cuối, Analytical modeling và Simulation, khá tương tự các kỹ thuật đánh giá hiệu
năng được sử dụng để phân tích hiệu năng của các hệ thống máy tính.

1.4! Phạm vi nghiên cứu của đề tài
11


Luận văn trình bày một cuộc khảo sát rộng rãi các phương pháp đánh giá khả năng sử
dụng , sau đó tập trung vào phân tích hai phương pháp phổ biến của phương pháp kiểm
duyệt là đánh giá dựa trên kinh nghiệm và đánh giá thăm dò (cognitive walkthrough).
Luận văn xác định các khía cạnh của việc đánh giá tính dễ sử dụng bằng hai kỹ thuật
này, áp dụng vào đánh giá tính dễ sử dụng của hệ thống cổng thông tin điện tử chính
phủ Việt nam. Cuối cùng là đề xuất các cải tiến cho việc thiết kế giao diện để hệ thống
cổng thông tin điện tử hoàn thiện và phục vụ tốt hơn cho cộng đồng.

12

Chương 2! Phương pháp kiểm duyệt để đánh giá
tính khả dụng của hệ thống
2.1! Phương pháp kiểm duyệt
Kiểm duyệt khả năng sử dụng [2] là một tập hợp các phương pháp trong đó người đánh
giá thẩm định hoặc kiểm tra các khía cạnh liên quan đến tính khả dụng của một giao
diện người dùng.
Những người kiểm duyệt tính khả dụng có thể là các chuyên gia, các nhà tư vấn phát
triển phần mềm có chuyên môn đặc biệt (chẳng hạn kiến thức về một dạng giao diện
người dùng cụ thể nào đó), người dùng cuối cùng có kiến thức về nội dung hoặc công
việc liên quan, hoặc có các chuyên môn khác.

2.2! Các hoạt động của quá trình kiểm duyệt
Về cơ bản, kiểm duyệt tính khả dụng nhằm tìm các vấn đề liên quan đến tính khả dụng
trong một bản thiết kế giao diện người dùng, sau đó đề xuất các lựa chọn để khắc phực
các vấn đề này và cả thiện tính khả dụng của bản thiết kế. Điều này có nghĩa là việc
kiểm duyệt tính khả dụng thường được tiến hành khi bản thiết kế giao diện đã hoàn
thành và tính khả dụng của nó với người dùng cần được đánh giá. Các hoạt động trong
quá trình kiểm duyệt gồm:
•! Xác định các vấn đề liên quan đến tính khả dụng.
•! Đánh giá tính khả dụng.
•! Đào tạo và xây dựng đội thiết kế nhằm cải thiện các vấn đề về tính khả
dụng.

2.2.1! Xác định các vấn đề liên quan đến tín khả dụng
Các vấn đề liên quan đến tính khả dụng có thể được định nghĩa như các đặc tính của
giao diện người dùng vốn có thể làm giảm tính khả dụng của hệ thống đối với người
dùng cuối. Tính khả dụng là một khái niệm khá rộng lớn, về cơ bản khái niệm này nói
đến tính dễ hiểu và dễ sử dụng của hệ thống với người dùng. Cũng như vậy, tần suất và

mức độ nghiêm trọng của lỗi người dùng cũng được xem là những thành phần của tính
khả dụng. Như vậy, một thành phần nào đó của giao diện được cho là có vấn đề đối với
người sử dụng bởi rất nhiều lý do: thành phần đó làm người dùng cảm thấy khó khăn
khi học cách sử dụng hệ thống, làm chậm hệ thống khi thực thi nhiệm vụ, tạo ra cá lỗi
sử dụng hoặc làm người dùng cảm thấy không thoải mái khi sử dụng hệ thống.

13


Kiểm duyệt tính khả dụng quan tâm đến việc phân loại và đếm số lượng các vấn đề liên
quan đến tính khả dụng. Nhìn chung, những phân tích như vậy dựa vào định nghĩa chính
xác các yếu tố cấu thành nên các vấn đề đó.

2.2.2! Chu trình đánh giá tính khả dụng
Việc xác định các vấn đề về giao diện người dùng thông qua kiểm tra hoặc kiểm duyệt
là rất quan trọng. Tuy vậy, nó chỉ là một phần của một quy trình lớn hơn thế. Sau khi
xây dựng danh sách các vấn đề liên quan đến tính khả dụng, một đội phát triển cần phải
thiết kế lại giao diện người dùng nhằm khắc phục các vấn đề nhiều nhất có thể. Thực
hiện công việc này đòi hỏi thêm các thông tin và phân tích khác. Ba điểm sau đây cho
chúng ta một cái nhìn tổng quan trong việc sử dụng các báo cáo về vấn đề kiểm duyệt
nhằm tạo ra một bản thiết kế có tầm ảnh hưởng:
Đưa ra cách khắc phục và các gợi ý cho việc thiết kế lại giao diện người dùng. Ở giai
đoạn này, chúng ta cũng cần phải lưu ý đến các phương pháp đánh giá khác nhằm tìm
ra các vấn đề một cách hiệu quả.
Để có thể sử dụng danh sách các vấn đề về tính khả dụng một cách hiệu quả, chúng ta
cần sắp xếp các vấn đề này theo thứ tự ưu tiên khác nhau dựa vào mức độ nghiêm trọng
của từng vần đề. Đánh giá mức độ nghiêm trọng thường dựa trên ước lượng của người
dùng hoặc mức độ ảnh hưởng của những vấn đề đó đối với thị trường.
Cuối cùng, chúng ta cần ước lượng chi phí phần mềm khi thiết kế lại giao diện người
dùng. Có một vài phương pháp kĩ nghệ phần mềm cho phép ước lượng chi phí lập trình.

Mặc dù độ chính xác của những phương pháp này không cao, chúng vẫn cung cấp thông
tin hữu ích cho viêc ước lượng chi phí - lợi nhuận. Ước lượng này sẽ được sử dụng để
đưa ra quyết định cuối cùng về những vấn đề liên quan đến tính khả dụng cần khắc
phục. Những vấn đề nghiêm trọng cần phải được khắc phục mà không cần quan tâm
đến chi phí. Thông thường, chúng ta có thể khắc phục khá nhiều vấn đề ít nghiêm trọng
hơn và gây ra ít thay đổi trong mã nguồn. Chúng ta cũng cần có các báo cáo về những
vấn đề mà người kiểm duyệt cho rằng chi phí quá tốn kém đề khắc phục bởi vì đôi khi
các đội thiết kế có thể phát triển những phương án thiết kế lại có chi phí thấp hơn.

2.2.3! Đào tạo và xây dựng đội thiết kế
Các phương pháp kiểm duyệt tính khả dụng hướng đến mục tiêu tạo ra mối giao tiếp
thông tin giữa các phương pháp kiểm duyệt nhóm. Điều này có lợi ích đáng kể vì những
người kiểm duyệt biết đến các vấn đề về tính khả dụng thông qua kiểm duyệt mà không
cần đến chuyên môn về tính khả dụng.

2.3! Các phương pháp kiểm duyệt
14


Các phương pháp kiểm duyệt (thẩm định) khác nhau hướng đến các mục đích đôi chút
khác nhau, nhưng thông thường kiểm định tính khả dụng nhằm mục đích đánh giá các
bản thiết kế giao diện người dùng, trong đó việc đánh giá giao diện người dùng dựa trên
ý kiến của những người thẩm định. Sự khác nhau giữa các phương pháp thẩm định riêng
biệt nằm ở hai khía cạnh: các ý kiến đánh giá được rút ra như thế nào và dựa trên các
tiêu chí đánh giá nào mà những người kiểm định đưa ra các ý kiến đó. Nhìn chung, việc
xác định các đặc tính của việc thẩm định tính khả dụng dựa trên các ý kiến đánh giá về
thành phần cụ thể nào đó của một giao diện người dùng.
Chúng ta có thể so sánh thẩm định với các phương pháp đánh giá khác. Có 4 cách cơ
bản để đánh giá giao diện người dùng là: tự động hóa (đánh giá tính khả dụng bằng cach
chạy phần mềm đánh giá với đầu vào là một đặc tả giao diện người dùng), dựa trên quan

sát hoặc thực nghiệm (đánh giá tính khả dụng bằng cách kiểm tra giao diện với người
dùng thực), hình thức hóa (sử dụng các mô hình và các công thức chính xác để tính toán
các đánh giá tính khả dụng), và phi hình thức (dựa vào các kỹ năng, kiến thức tổng quát
và kinh nghiệm của những người thẩm định). Thẩm định tính khả dụng thuộc về phân
lớp các phương pháp phi hình thức, trong đó việc đánh giá dựa vào kinh nghiệm của
người thẩm định.
Hiện nay, các phương pháp tự động không khả thi, các phương pháp hình thức rất khó
có thể áp dụng đối với giao diện người dùng phức tạp và có độ tương tác cao. Các
phương pháp thực nghiệm dựa trên kiểm tra người dùng là cách chủ yếu và được sử
dụng phổ biến nhất để đánh giá giao diện người dùng. Thông thường, việc đánh giá tất
cả các khía cạnh của một thiết kế giao diện dựa trên người dùng thực là khó khăn và
tốn kém. Vì vậy, các phương pháp thẩm định chính là cách “tiết kiệm người dùng”.
Những nghiên cứu về các phương pháp kiểm duyệt tính khả dụng cho thấy rằng phương
pháp kiểm tra người dùng đã bỏ qua rất nhiều vấn đề về tính khả dụng. Tuy nhiên, kiểm
tra người dùng cũng chỉ ra một số vấn đề mà phương pháp kiểm duyệt không chú ý tới.
Như vậy, để đạt được kết quả tốt nhất chúng ta cần kế hợp kiểm tra thực nghiệm và
kiểm duyệt.
Kiểm duyệt tính khả dụng là thuật ngữ chung dành cho nhiều phương pháp khác nhau,
trong đó có 8 phương pháp sau [8]:
•! Đánh giá dựa trên kinh nghiệm (Hueristic evaluation): là phương pháp sử dụng
đánh giá của các chuyên gia. Các đánh giá sử dụng các nguyên tắc về tính khả
dụng dựa trên kinh nghiệm. Phương pháp này thuộc nhóm các phương pháp phi
hình thức. Việc đánh giá là hoàn toàn dựa trên kinh nghiệm.

15


•! Đánh giá các tiêu chuẩn (Standards inspections). Với phương pháp này các
chuyên gia đánh giá xem giao diện có tuân theo tiêu chuẩn hay không?
•! Xem xét dựa trên bản hướng dẫn thiết kế (Guiline reviews): là phương pháp kiểm

tra xem một giao diện có phù hợp với hướng dẫn về tính khả dụng hay không.
Trong thực tế, tài liệu hướng dẫn là đồ sộ: mỗi tài liệu chứa hàng nghìn hướng
dẫn. Sử dụng phương pháp này yêu cầu cao về mức độ thành thạo nên khả năng
thực thi không cao. Đây có thể coi như một sự pha trộn giữa đánh giá dựa trên
kinh nghiệm và kiểm duyệt các tiêu chuẩn.
•! Thảo luận đa phương (Pluralistic walkthroughs). Với phương pháp này người
dùng và người phát triển cùng rà soát lại các tình huống sau đó thảo luận các vấn
đề liên quan đến tình huống đó.
•! Kiểm duyệt tính nhất quán (Consistency inspections). Là phương pháp kiểm tra
xem giao diện có tuân thủ theo bản thiết kế hay không. Mục tiêu: đánh giá tính
nhất quán của một nhóm sản phẩm.
•! Kiểm duyệt chức năng (Feature inspections). Phương pháp tập trung vào chức
năng của hệ thống phần mềm nhằm kiểm tra xem chức năng của hệ thống có đáp
ứng nhu cầu người dùng cuối không?
•! Kiểm duyệt hình thức (Fomal usability inspections): tương tự như phương pháp
kiểm duyệt mã nguồn, người tham gia gồm có: đội phát triển sản phẩm và người
kiểm duyệt. Nhiệm vụ:
o! Người kiểm duyệt: Lập kế hoạch, chuẩn bị cho buổi họp, Kiểm duyệt
riêng từng giao diện, ghi lại các sai sót, tổng hợp danh sách các vấn
đề về tính khả dụng, đánh giá mức độ hiệu quả của quá trình kiểm
duyệt.
o! Đội phát triển: chịu trách nhiệm về các thiết kế.
•! Kiểm duyệt bằng cách thăm dò (Cognitive walkthroughs). Là phương pháp có
quy trình rõ ràng, mô phỏng quá trình giải quyết vấn đề của người dùng trong
mỗi bước giao tiếp giữa người và máy. Các hoạt động chủ yếu là: xác định đầu
vào (người dùng, tác vụ mẫu, các mô tả phần cài đặt giao diện, kịch bản để hoàn
thành nhiệm vụ), tiến hành phân tích các vấn đề cùng giải pháp, đưa ra các giả
thuyết về các nhiệm vụ và kinh nghiệm của người dùng, Cuối cùng là xem xét
chuỗi các hành vi cho từng nhiệm vụ, ghi lại các thông tin phản biện, và xem lại
các giao diện để khắc phục vấn đề.

Trong tài liệu này chúng tôi xin trình bày tập trung vào hai phương pháp mà chúng tôi
sử dụng để đánh giá tính hiệu quả sử dụng của hệ thống cổng thông tin điện tử chính

16


phủ Việt Nam là: đánh giá tính khả dụng dựa trên kinh nghiệm và kỹ thuật đánh giá khả
năng sử dụng bằng phương pháp thăm dò.

2.3.1! Phương pháp đánh giá dựa trên kinh nghiệm
2.3.1.1! Làm thế nào để hiện thực hóa một đánh giá dựa trên kinh nghiệm
Đánh giá dựa trên kinh nghiệm (heuristic evaluation) [6] là phương pháp đánh giá trong
đó những người đánh giá kiểm tra giao diện và đánh giá mức độ phù hợp của giao diện
đối với các nguyên tắc khả dụng (hay còn gọi là "kinh nghiệm").
Đánh giá dựa trên kinh nghiệm là kĩ thuật đánh giá tính khả dụng nhằm tìm ra các vấn
đề về tính khả trong một bản thiết kế giao diện người dùng, qua đó xem xét những vấn
đề này như một phần của quá trình thiết kế lặp đi lặp lại. Đánh giá dựa trên kinh nghiệm
liên quan đến việc có một nhóm nhỏ những người đánh giá kiểm tra giao diện và đánh
giá mức độ phù hợp của giao diện đối với các nguyên tắc khả dụng (các "kinh nghiệm").
Nhìn chung, việc đánh giá dựa trên kinh nghiệm rất khó khăn đối với một cá nhân đơn
lẻ, bởi vì một người không thể tìm được hết tất cả các vấn đề về tính khả trong một
giao diện. Tuy nhiên rất may mắn rằng, kinh nghiệm đúc kết từ rất nhiều dự án cho thấy
rằng nhiều người khác nhau tìm ra được những vấn đề khác nhau. Do vậy, hiệu quả của
phương pháp này được cải thiện đáng kể khi kết hợp nhiều người cùng đánh giá. Hình
1 minh họa một ví dụ trong đó 19 người đánh giá tìm ra 16 vấn đề về tính khả trong
một hệ thống trả lời bằng giọng nói. Hệ thống này cho phép khách hàng truy cập vào
tài khoản ngân hàng của họ (Nielsen 1992). Mỗi hình vuông màu đen trong hình 1 minh
họa một vấn đề được tìm thấy bởi một người đánh giá. Hình vẽ này cho thấy rõ ràng
rằng có một số lượng đáng kể các vấn đề không được tìm thấy bởi bất kì người đánh
giá nào. Ta cũng thấy rõ rằng các vấn đề dễ phát hiện thường được tìm thấy bởi hầu hết

tất cả những người đánh giá. Tuy vậy, cũng có một số vấn đề được tìm thấy bởi rất ít
người đánh giá. Hơn nữa, ta không thể xác định người đánh giá tốt nhất nếu chỉ dựa
trên những phát hiện của người đó. Thứ nhất, người đánh giá tốt nhất không nhất thiết
luôn luôn là tốt nhất. Thứ hai, một số vấn đề khó tìm thấy nhất (được biểu diễn bởi các
cột ngoài cùng bên trái trong hình 1) lại được tìm thấy bởi những người đánh giá có ít
phát hiện. Vì vậy trong phương pháp đánh giá dựa trên kinh nghiệm, việc xem xét đến
nhiều người đánh giá là rất cần thiết. Thông thường, ta nên sử dụng 3-5 người đánh giá,
bởi vì việc sử dụng một số lượng người đánh giá lớn hơn không đưa lại cho ta nhiều
thông tin bổ sung.

17


Hình 1: Mối liên quan giữa lỗi khả dụng tìm thấy với tập người đánh giá [6]
Để tiến hành đánh giá dựa trên kinh nghiệm, mỗi người đánh giá kiểm tra giao diện một
cách độc lập. Chỉ sau khi tất cả các đánh giá đã được hoàn thành, những người đánh
giá mới được phép trao đổi và tổng hợp và có những phát hiện của họ. Thủ tục này là
rất quan trọng để đảm bảo tính độc lập và công bằng cho các đánh giá. Những người
đánh giá có thể ghi lại các kết quả đánh giá bằng văn bản hoặc diễn đạt nhận xét của
họ bằng lời với người quan sát khi họ xem xét giao diện. Báo cáo bằng văn bản có lợi
thế trong việc trình bày kết quả đánh giá, nhưng đòi hỏi những người đánh giá phải nỗ
lực hơn, đồng thời đòi hỏi người quản lý đánh giá phải đọc và tổng hợp các đánh giá.
Sử dụng một người quan sát làm tăng tổng phí của mỗi phiên đánh giá, nhưng làm giảm
khối lượng công việc của những người đánh giá. Ngoài ra, các kết quả đánh giá có khá
sớm sau phiên đánh giá cuối cùng, bởi vì người quan sát chỉ cần hiểu và tổ chức các ghi
chú của mình chứ không phải xem xét các báo cáo của những người khác. Hơn nữa,
người quan sát có thể giúp đỡ những người đánh giá trong việc vận hành giao diện khi
có vấn đề xảy ra, chẳng hạn như một hệ thống thử nghiệm không ổn định. Ngoài ra,
người quan sát cần trợ giúp khi những người đánh giá có ít kinh nghiệm chuyên môn
hoặc khi họ cần được giải thích một khía cạnh cụ thể nào đó của giao diện.

Trong một tình huống thử nghiệm người dùng, người quan sát (thường được gọi là
"người thực hiện thí nghiệm") có trách nhiệm giải thích hành vi của người sử dụng, từ
đó suy ra những hành động đó có liên quan đến các vấn đề về tính khả dụng trong việc
thiết kế giao diện như thế nào. Điều này cho phép tiến hành thử nghiệm người dùng
ngay cả khi những người dùng đó không biết gì về thiết kế giao diện. Trái lại, người
đánh giá có trách nhiệm phân tích giao diện người dùng trong phiên đánh giá. Do đó,

18


người quan sát chỉ cần ghi lại ý kiến của người đánh giá về giao diện, nhưng không cần
phải giải thích những hành vi của người đánh giá.
Có thêm hai sự khác biệt giữa đánh giá dựa trên kinh nghiệm và thử nghiệm người dùng
truyền thống. Trong thử nghiệm người dùng truyền thống, ta thường muốn tìm những
lỗi mà người dùng mắc phải khi sử dụng giao diện; do đó những người thực hiện thí
nghiệm phải trợ giúp người dùng nhiều hơn mức cần thiết. Ngoài ra, người dùng phải
tự khám phá ra câu trả lời cho các câu hỏi của mình thông qua việc sử dụng hệ thống,
chứ không phải thông qua người thực hiện thí nghiệm. Khi đánh giá một ứng dụng trong
miền cụ thể dựa trên kinh nghiệm, việc từ chối trả lời những câu hỏi của người đánh giá
được coi là không hợp lý, đặc biệt là khi những người đánh giá không phải là chuyên
gia về miền ứng dụng đó. Việc trả lời các câu hỏi của người đánh giá sẽ giúp họ đánh
giá tốt hơn tính khả dụng của giao diện người dùng tương ứng với đặc điểm của miền
ứng dụng. Tương tự như vậy, khi người đánh giá gặp vấn đề trong sử dụng giao diện,
họ có thể được gợi ý về cách thức tiến hành để không lãng phí thời gian đánh giá quý
báu vật lộn với giao diện. Tuy vậy, điều quan trọng cần lưu ý là ta không nên trợ giúp
những người đánh giá cho đến khi họ thực sự gặp rắc rối và chú thích những vấn đề về
tính khả cần được cân nhắc.
Một phiên đánh giá dựa trên kinh nghiệm cho một người đánh giá thường kéo dài một
hoặc hai giờ. Đối với giao diện phức tạp, có số lượng hội thoại lớn, những phiên đánh
giá cần thiết phải kéo dài hơn. Tuy nhiên, sẽ được tốt hơn nếu ta chia phiên đánh giá ra

thành nhiều phiên nhỏ hơn, mỗi phiên tập trung vào một phần nào đó của giao diện.
Trong phiên họp đánh giá, người đánh giá phải duyệt qua các giao diện nhiều lần, kiểm
tra các hội thoại khác nhau và so sánh chúng với một danh sách các nguyên tắc khả
dụng (hay còn gọi là các kinh nghiệm). Những kinh nghiệm này là những quy tắc mô
tả thuộc tính chung của các giao diện dễ dùng. Ngoài những kinh nghiệm chung cần
phải cân nhắc, người đánh giá vẫn được phép xem xét bất kỳ nguyên tắc hoặc kết quả
bổ sung có liên quan đến một hội thoại cụ thể nào đó. Hơn nữa, ta có thể phát triển
những kinh nghiệm để áp dụng cho một phân lớp cụ thể của sản phẩm, Những kinh
nghiệm mang tính đặc thù này sẽ bổ sung cho các các kinh nghiệm mang tính tổng quát
hơn. Ta có thể xây dựng những kinh nghiệm bổ sung này bằng cách tiến hành các phân
tích và thử nghiệm người dùng trên các sản phầm hiện có nằm trong một hạng mục nhất
định, và cố gắng trừu tượng hóa các nguyên tắc nhằm giải thích các vấn đề về tính khả
được tìm thấy (Dykstra 1993).
Về nguyên tắc, người đánh giá tự quyết định cách thức tiến hành việc đánh giá giao
diện. Tuy nhiên, họ nên duyệt qua giao diện ít nhất hai lần. Ở lần duyệt đầu tiên, người
đánh giá sẽ có những hình dung về luồng tương tác và phạm vi chung của hệ thống. Lần

19


duyệt thứ hai cho phép người đánh giá tập trung vào các yếu tố giao diện cụ thể.
Do người đánh giá không sử dụng hệ thống như vậy (để thực hiện một tác vụ), họ có
thể thực hiện việc đánh giá cho dù giao diện người dùng chỉ được mô tả trên giấy và
chưa được cài đặt (Nielsen 1990). Điều này cho phép sử dụng đánh giá dựa trên kinh
nghiệm ở giai đoạn sớm trong chu trình đánh giá tính khả dụng.
Nếu hệ thống là giao diện dễ dùng dành cho đa số người dùng nói chung hoặc nếu
những người đánh giá chỉ có chuyên môn về những miền ứng dụng nhất định, khi đó
các đánh giá viên có thể sử dụng hệ thống mà không cần trợ giúp thêm. Nếu người
đánh giá không thực sự hiểu rõ hệ thống, thì việc hỗ trợ họ trong việc sử dụng giao diện
là rất cần thiết . Một cách tiếp cận đã được áp dụng thành công đó là cung cấp một kịch

bản sử dụng điển hình cho các đánh giá viên, trong đó liệt kê các bước khác nhau mà
người dùng cần thực hiện nhằm hoàn thành một tập mẫu gồm các công việc thực tế.
Một kịch bản như vậy phải được xây dựng trên cơ sở phân tích nhiệm vụ của người
dùng và công việc của họ.
Đầu ra của phương pháp đánh giá dựa trên kinh nghiệm là một danh sách các vấn đề
của giao diện liên quan đến tính khả dụng, trong đó có đề cập đến những nguyên tắc
khả dụng đã bị vi phạm theo quan điểm của người đánh giá. Sẽ là không thỏa đáng nếu
người đánh giá chỉ nói rằng họ không thích một cái gì đó; mà thay vào đó, họ cần giải
thích lý do tại sao họ không thích giao diện đó. Các đánh giá viên nên cố gắng càng cụ
thể càng tốt và nên liệt kê từng vấn đề về tính khả dụng một cách riêng biệt.
Đánh giá dựa trên kinh nghiệm không cho phép khắc phục các vấn đề về tính khả dụng
hoặc đánh giá chất lượng của bất kỳ bản tái thiết kế nào một cách có hệ thống. Tuy
nhiên, vì đánh giá dựa trên kinh nghiệm nhằm mục đích giải thích từng vấn đề về tính
khả dụng quan sát được bằng cách tham khảo các nguyên tắc khả dụng, việc sửa đổi
bản thiết kế là khá dễ dàng. Ngoài ra, nhiều vấn đề về tính khả dụng có bản sửa lỗi khá
rõ ràng ngay sau khi các vấn đề này được xác định.
Ví dụ, nếu vấn đề đó là việc người dùng không thể sao chép thông tin từ một cửa sổ này
sang một cửa sổ khác, thì giải pháp hiển nhiên cho vấn đề này là cung cấp một tính năng
sao chép như vậy. Tương tự như vậy, nếu vấn đề là việc sử dụng các phông chữ và định
dạng chữ hoa / chữ thường không phù hợp, thì giải pháp rõ ràng là lựa chọn một định
dạng duy nhất cho toàn bộ giao diện. Tuy nhiên, ngay cả đối với những ví dụ đơn giản,
người thiết kế không có thông tin để giúp thiết kế các thay đổi chính xác cho giao diện
(ví dụ, làm thế nào để cho phép người dùng sao chép thông tin hoặc lựa chọn định dạng
font chữ nào để chuẩn hóa).

20


2.3.1.2! Xếp hạng mức độ nghiêm trọng của các vấn đề khả dụng
Xếp hạng mức độ nghiêm trọng có thể được sử dụng để phân bổ nguồn lực nhằm khắc

phục những vấn đề nghiêm trọng nhất. Nếu vấn đề khả dụng tìm thấy trong giao diện
được đánh giá là nghiêm trọng thì giao diện đó không nên đưa vào sử dụng.
Mức độ nghiêm trọng của một vấn đề khả dụng là một sự kết hợp của ba yếu tố:
o! Tần suất mà vấn đề xảy ra: thường xuyên hoặc hiếm khi xảy ra?
o! Tác động của vấn đề nếu nó xảy ra: nó dễ dàng hay khó khắc phục?
o! Thời gian tồn tại của vấn đề: Vấn đề có thể được khắc phục một lần, ngay sau
khi người dùng nhận ra nó, hay là liên tục lặp đi lặp lại?
o! Cuối cùng, ta tất nhiên cần phải đánh giá khia cạnh tác động của thị trường
của vấn đề, bởi vì một số vấn đề khả dụng nhất định có thể có một tác động
xấu đến một sản phẩm, ngay cả khi những vấn đề này có thể dễ dàng khắc
phục được. Mặc dù mức độ nghiêm trọng bao gồm nhiều thành phần, tất cả
các khía cạnh của mức độ nghiêm trọng thường được kết hợp với nhau trong
một đánh giá mức độ nghiêm trọng duy nhất, Đánh giá này hỗ trợ cho việc ưu
tiên và ra quyết định.
Các đánh giá từ 0-4 sau đây được sử dụng để đánh giá mức độ nghiêm trọng của các
vấn đề khả dụng:
o! 0 = Đây không phải là vấn đề khả dụng
o! 1 = Vấn đề này không cần khắc phục, trừ khi dự án có thêm thời gian
o! 2= Đây là vấn để khả dụng nhỏ: việc khắc phục nó sẽ được gán mức độ ưu
tiên thấp
o! 3= Đây là vấn để khả dụng lớn: việc khắc phục nó là quan trọng và có mức
ưu tiên cao
o! 4= Đây là vấn đề nghiêm trọng: cần phải khẩn trương khắc phục nó trước khi
sản phầm được đưa vào sử dụng.
Rất khó để có được một ước lượng mức độ nghiêm trọng tốt thông qua người đánh giá
khi ta sử dụng phương pháp đánh giá dựa trên kinh nghiệm. Bởi vì những người đánh
giá tập trung đa số thời gian vào việc tìm kiếm các vấn đề khả dụng mới. Hơn nữa, mỗi
người đánh giá sẽ chỉ tìm thấy một số lượng nhỏ các vấn đề khả dụng, do đó xếp hạng
mức độ nghiêm trọng của các vấn đề mà họ tìm thấy là không đầy đủ. Thay vào đó, ta
có thể xếp hạng mức độ nghiêm trọng bằng cách gửi một bảng các câu hỏi đến các đánh

giá viên sau những buổi đánh giá thực tế, liệt kê toàn bộ các vấn đề đã được phát hiện,
và yêu cầu họ đánh giá mức độ nghiêm trọng của từng vấn đề. Vì mỗi người đánh giá
đã chỉ xác định một tập hợp con của các vấn đề có trong danh sách, những vấn đề này

21


cần phải được mô tả chi tiết. Người quan sát việc đánh giá có thể tổng hợp các mô tả
bằng cách gộp các ý kiến của những người đánh giá (hoặc, nếu các báo cáo đánh giá
được viết bằng văn bản thì các mô tả có thể được tổng hợp từ những mô tả trong báo
cáo). Những mô tả này cho phép người đánh giá có thể đánh giá các vấn đề khác nhau
khá dễ dàng ngay cả khi bản thân họ không tìm thấy chúng trong phiên đánh giá của
mình. Thông thường, người đánh giá cần chỉ dành khoảng 30 phút để hoàn thành xếp
hạng mức độ nghiêm trọng. Điều quan trọng cần lưu ý là mỗi người đánh giá nên đưa
ra xếp hạng mức độ nghiêm trọng của mình một cách độc lập với các đánh giá khác.
Kinh nghiệm cho thấy xếp hạng mức độ nghiêm trọng do một người đánh giá đưa ra là
không đáng tin cậy. Nhưng khi yêu cầu nhiều người cùng đưa ra đánh giá mức độ
nghiêm trọng của các vấn đề khả dụng, thì chất lượng trung bình của các đánh giá này
tăng lên nhanh chóng. Trong thực tiễn, việc sử dụng giá trị trung bình của một tập hợp
các xếp hạng do ba người đánh giá đưa ra là đạt yêu cầu.
2.3.1.3! Xác định số lượng người đánh giá
Về nguyên tắc, những người đánh giá có thể tự mình tiến hành một đánh giá dựa trên
kinh nghiệm, tuy nhiên kinh nghiệm từ một số dự án cho thấy kết quả thu được dựa trên
những đánh giá đơn lẻ là khá nghèo nàn. Trung bình trên sáu dự án, các đánh giá đơn
lẻ chỉ tìm thấy 35 phần trăm trong những vấn đề về tính khả dụng trong các giao diện.
Tuy nhiên, do các đánh giá khác nhau có xu hướng tìm ra các vấn đề khác nhau, ta có
thể đạt được hiệu suất tốt hơn đáng kể bằng cách tập hợp các đánh giá từ nhiều người
đánh giá.

Hình 2: Tỉ trọng lỗi khả dụng trên số người đánh giá [6]

22


Hình 2 cho thấy tỷ trọng của các vấn đề về tính khả dụng được tìm thấy khi càng có
nhiều người đánh giá được thêm vào. Biểu đồ này cho thấy rõ ràng rằng có một tỉ lệ
phần trăm cao từ việc sử dụng nhiều hơn một người đánh giá. Sử dụng khoảng năm
người đánh giá là hợp lý, nhưng chắc chắn ít nhất ba. Việc sử dụng chính xác bao nhiêu
người đánh giá phụ thuộc vào phân tích chi phí - lợi ích. Ta rõ ràng cần sử dụng nhiều
người đánh giá hơn trong trường hợp mà tính khả dụng trở nên rất quan trọng.
Để xác định số lượng người đánh giá tối ưu, ta cần một mô hình chi phí - lợi ích cho
phương pháp đánh giá dựa trên kinh nghiệm. Yếu tố đầu tiên trong một mô hình như
vậy là các chi phí của việc sử dụng phương pháp, xem xét cả chi phí cố định và chi phí
biến đổi. Chi phí cố định là chi phí cần phải trả mà không cần biết đến có bao nhiêu
người đánh giá đang được sử dụng; những chi phí này bao gồm thời gian để lên kế
hoạch đánh giá, chuẩn bị tài liệu, và viết báo cáo hoặc thông báo các kết quả. Chi phí
biến đổi là những chi phí bổ sung được tích luỹ khi có thêm một người đánh giá được
sử dụng; những chi phí này bao gồm mức lương của người đánh giá cũng như các chi
phí dành cho việc phân tích báo cáo của người đánh giá đó và chi phí của bất kỳ tài
nguyên máy tính hoặc các nguồn tài nguyên khác được sử dụng trong phiên đánh giá.
Hiển nhiên các chi phí cố định và biến đổi thực sẽ thay đổi phụ thuộc vào từng dự án
cũng như cơ cấu chi phí của mỗi công ty và vào sự phức tạp của giao diện được đánh
giá. Những lợi ích mà phương pháp đánh giá dựa trên kinh nghiệm mang lại chủ yếu từ
việc tìm ra các vấn đề khả dụng, mặc dù phương pháp này cũng mang lại một số lợi ích
giáo dục bằng cách nâng cao hiểu biết của những người đánh giá về khả năng sử dụng
khi họ so sánh các báo cáo đánh giá của riêng mình với những đánh giá khác.
2.3.1.4! Các đặc trưng của những vấn đề khả dụng được tìm thấy bởi phương
pháp đánh giá dựa trên kinh nghiệm
Đánh giá dựa trên kinh nghiệm là một phương pháp hiệu quả nhằm xác định những vấn
đề lớn và nhỏ trong giao diện [7]. Phương pháp đánh giá dựa trên kinh nghiệm và kiểm

tra người dùng đều có thể làm sót lỗi, do đó cách tốt nhất là sử dụng cả hai phương pháp
này.
Đánh giá dựa trên kinh nghiệm là một phương pháp tốt nhằm tìm kiếm các vấn đề cả
lớn và nhỏ trong một giao diện người dùng. Các vấn đề lớn thường dễ tìm hơn là các
vấn đề nhỏ. Trong thử nghiệm của Nielsen năm 1992 với 6 trường hợp, xác suất để tìm
thấy một vấn đề lớn cho trước là 42%, trong khi đó xác suất này là 32% đối với một
vấn đề nhỏ cho trước.
Mặc dù các vấn đề lớn dễ được tìm thấy hơn, điều đó không có nghĩa là người đánh giá
hoàn toàn tập trung vào các vấn đề lớn. Thử nghiệm của Nielsen năm 1992 cho thấy

23


đánh giá dựa trên kinh nghiệm xác định được tổng cộng 59 vấn đề khả dụng lớn và 152
vấn đề nhỏ. Như vậy, số lượng các vấn đề khả dụng nhỏ được tìm thấy có khuynh hướng
vượt trội hơn hẳn. Đây là lý do vì sao việc xếp hạng mức độ nghiêm trọng của các vấn
đề khả dụng là một sự bổ sung hữu ích cho phương pháp này.
Theo định nghĩa, các vấn đề khả dụng lớn là những vấn đề quan trọng để tìm và khắc
phục. Tuy nhiên, các vấn đề nhỏ vẫn có sự liên quan chặt chẽ. Nhiều vấn đề nhỏ như
vậy có vẻ như dễ dàng tìm thấy bằng cách đánh giá dựa trên kinh nghiệm hơn là bằng
các phương pháp khác. Một ví dụ về một vấn đề nhỏ được tìm thấy bằng phương pháp
đánh giá dựa trên kinh nghiệm là việc sử dụng các kiểu chữ không phù hợp trong hai
phần của một giao diện người dùng. Một thông tin được hiển thị ở cả hai định dạng
phông serif và sans serif. Điều này làm chậm tiến độ công việc của người dùng, bởi vì
họ phải mất thời gian để khớp hai mẩu thông tin với nhau. Đây là một dạng vấn đề nhỏ
mà ta không thể quan sát được khi làm thử nghiệm người dùng, trừ khi ta phân tích một
cách cẩn thận các tương tác với người dùng. Những tương tác này phải được ghi hình
hoặc lưu trữ lại.
Các vấn đề khả dụng có thể xuất hiện trong một hội thoại theo bốn cách khác nhau.
o! Thứ nhất, vấn đề có thể xuất hiện tại một vị trí duy nhất trong giao diện.

o! Thứ hai, vấn đề xuất hiện tại hai hoặc nhiều vị trí trong đó để tìm ra vấn đề
ta phải so sánh các vị trí này với nhau.
o! Thứ ba, vấn đề có thể liên quan đến cấu trúc tổng thể của giao diện.
o! Cuối cùng, vấn đề xuất hiện khi một phần nào đó đáng lẽ phải đưa vào giao
diện nhưng hiện bị thiếu sót.
Một phân tích trên 211 vấn đề khả dụng (Nielsen 1992) cho thấy rằng sự khác biệt giữa
bốn phân loại vị trí trên là nhỏ và không đáng kể về mặt thống kê. Nói cách khác, người
đánh giá có thể tìm thấy tất cả bốn loại vấn đề khả dụng với hiệu quả như nhau. Tuy
nhiên, hiệu ứng tương tác giữa phân loại vị trí và phần cái đặt giao diện là đáng kể và
có ảnh hưởng rất lớn. Các vấn đề trong phân loại "cái gì đó thiếu" dễ được tìm thấy hơn
các vấn đề khác khi kiểm tra các hệ thống đang chạy, nhưng khó tìm hơn các vấn đề
khác khi kiểm tra các chương trình chạy thử viết trên giấy. Hiện tượng này là do người
đánh giá khi sử dụng một hệ thống đang chạy dễ gặp phải vấn đề khi có một yếu tố cần
thiết nào đó của giao diện bị thiếu sót (và như vậy sẽ nhận thấy được vấn đề). Trái lại,
người đánh giá khi xem xét phần cài đặt trên giấy chỉ cần chuyển sang trang tiếp theo
và tập trung vào các yếu tố giao diện tìm thấy ở đó. Như vậy, họ khó có thể phát hiện
được yếu tố còn thiếu sót của giao diện.

24


Sử dụng xen kẽ hai phương pháp đánh giá dựa trên kinh nghiệm và thử nghiệm người
dùng. Một mặt, phương pháp đánh giá dựa trên kinh nghiệm có thể tìm thấy nhiều vấn
đề khả dụng mà cách thử nghiệm người dùng không tìm ra được. Mặt khác, phương
pháp này vẫn có thể bỏ qua một số vấn đề mà bằng phương pháp thử nghiệm người
dùng ta có thể tìm ra. Hơn nữa, người đánh giá có thể bỏ qua các vấn đề khi xem xét hệ
thống mà họ không có chuyên môn về nó. Ta hầu như không thể tìm thấy những vấn đề
như vậy nếu không sử dụng phương pháp thử nghiệm người dùng.
Cả hai phương pháp đánh giá dựa trên kinh nghiệm và thử nghiệm người dùng có thể
tìm thấy những vấn đề khả dụng mà phương pháp còn lại bỏ qua. Do đó ta nên sử dụng

cả hai phương pháp này. Thông thường, cách tốt nhất là sử dụng xen kẽ hai phương
pháp đánh giá. Đầu tiên, ta sử dụng phương pháp đánh giá dựa trên kinh nghiệm để dọn
dẹp giao diện và loại bỏ càng nhiều các vấn đề “hiển nhiên” càng tốt. Sau khi thiết kế
lại giao diện, ta tiến hành thử nghiệm người dùng để kiểm tra kết quả của các bước thiết
kế trước đó và tìm các vấn đề còn lại mà đánh giá dựa trên kinh nghiệm không phát
hiện được.
Có hai lý do chính giải thích cho việc xen kẽ giữa đánh giá dựa trên kinh nghiệm và thử
nghiệm người dùng như đề xuất ở đây. Thứ nhất, đánh giá dựa trên kinh nghiệm có thể
loại bỏ một số vấn đề khả dụng mà không cần đến người dùng. Thứ hai, các vấn đề tìm
ra bởi mỗi phương pháp là tương đối khác biệt và không trùng lặp, Do đó, các phương
pháp này có thể bổ sung cho nhau.

2.3.2! Phương pháp đánh giá thăm dò
2.3.2.1! Tổng quan
Kiểm tra chu trình nghiệp vụ dựa trên kinh nghiệm [1] là một phương pháp kiểm tra
khả năng sử dụng, trong đó nó tập trung vào việc đánh giá tính dễ sử dụng của một bản
thiết kế bằng cách thăm dò. Sở dĩ như vậy là bởi vì nhiều người dùng muốn tìm hiểu
phần mềm bằng cách thăm dò. Thay vì đầu tư thời gian cho việc đào tạo người dùng
khi sử dụng một gói phần mềm, người dùng thích tìm hiểu về chức năng của sản phẩm
trong quá trình thực hiện các công việc của mình, qua đó họ có được kiến thức về làm
thế nào để sử dụng các tính năng mới mà công việc của họ thực sự cần đến. Hướng tiếp
cận này đảm bảo rằng chi phí để học một tính năng mới phần nào đó được xác định bởi
lợi ích trước mắt của tính năng này đối với người sử dụng.
Mô tả ngắn gọn về quy trình kiểm tra chu trình nghiệp vụ
Kiểm tra chu trình nghiệp vụ dựa trên kinh nghiệm có cùng cách tổ chức giống như
các dạng kiểm tra thiết kế khác, chẳng hạn như kiểm tra yêu cầu và kiểm tra mã nguồn

25