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

15 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

ĐẠ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

5

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

4

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!

5

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!

6

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!

7

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!

8

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

Đá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

10

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

11

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

12

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

13

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:

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

14

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

15

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

•! 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

17

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

18

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 đó,

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

20

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)

21

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

22

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]

23

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

24

đá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

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

26

(Yourdon 1989) Kiểm tra chu trình nghiệp vụ dựa trên kinh nghiệm là một quá trình trong đó người chịu trách nhiệm một phần nào đó của bản thiết kế sẽ trình bày đề xuất của mình cho một nhóm những người kiểm tra Người kiểm tra sẽ đánh giá giải pháp được đề xuất bằng cách sử dụng các tiêu chí phù hợp

Trong kiểm tra chu trình nghiệp vụ dựa trên kinh nghiệm, người kiểm tra sẽ đánh giá giao diện được đề xuất thông qua nhiều tác vụ người dùng cụ thể Một phiên kiểm tra yêu cầu các thông tin bao gồm mô tả thiết kế chi tiết của một giao diện, một kịch bản thực hiện tác vụ, các giả thiết rõ ràng về mật độ người dùng và bối cảnh sử dụng, và một chuỗi các thao tác mà một người sử dụng cần thực hiện để hoàn thành tác vụ đã được thiết kế trước

Trong quá trình kiểm tra chu trình nghiệp vụ, nhóm sẽ lần lượt xem xét từng thao tác của người dùng Đối với mỗi thao tác, người phân tích cố gắng thuật lại quá trình tương tác của người dùng với giao diện Người phân tích cần đặt ra câu hỏi, chẳng hạn như người dùng cần phải làm gì vào một thời điểm này và những thao tác nào được giao diện hỗ trợ Một thiết kế giao diện tốt cho phép người sử dụng lựa chọn được thao tác thích hợp Sau khi người sử dụng thực hiện thao tác đó, giao diện phải đưa ra thông tin phản hồi rõ ràng cho người dùng thấy được tiến bộ hoàn thành tác vụ của mình

2.3.2.2! Mô tả chi tiết thủ tục kiểm tra chu trình nghiệp vụ

Một phân tích sử dụng phương pháp kiểm tra thăm dò có hai khâu: khâu chuẩn bị và khâu phân tích Trong khâu chuẩn bị những người phân tích thống nhất về các điều kiện đầu vào cho việc kiểm tra, bao gồm: các chuỗi thao tác cho từng tác vụ, mật độ người dùng, và giao diện cần phân tích Công việc phân tích chính xuất hiện ở khâu thứ hai, trong đó những người phân tích xem xét từng thao tác của từng tác vụ đang được phân tích

2.3.2.2.1! Phương pháp kiểm tra chu trình nghiệp vụ của doanh nghiệp tương

thích với quy trình phát triển như thế nào

Kiểm tra chu trình nghiệp vụ dựa trên kinh nghiệm là phương pháp kiểm tra khả năng sử dụng nhằm đánh giá tính dễ học của một bản thiết kế thông qua thăm dò Đánh giá này được thực hiện sau phần đặc tả tương đối chi tiết của bản thiết kế giao diện người dùng Phần đặc tả này xuất hiện sau phần phân tích yêu cầu và định nghĩa về chức năng của ứng dụng

Phương pháp kiểm tra chu trình nghiệp vụ này có thể là một quy trình nhóm hoặc đơn lẻ Đối với đánh giá nhóm, người thiết kế trình bày bản thiết kế của mình trước những người kiểm tra Dựa trên những thông tin phản hồi, người thiết kế sửa đổi và cải thiện bản thiết kế cho lần kiểm tra tiếp theo Nhóm kiểm tra có thể gồm những người thiết kế khác, các kĩ sư phần mềm, hoặc đại diện của các đơn vị tổ chức chẳng hạn như các tổ chức về tiếp thị sản phẩm Thêm nữa, có thể có sự góp mặt của các chuyên gia đánh giá giao diện Mỗi thành viên của đội đánh giá có

27

vai trò nhất định: Một người có nhiệm vụ sao chép và ghi lại thông tin, một người làm cố vấn viên Những người còn lại đóng góp những kiến thức của mình ở nhiều lĩnh vực khác nhau, chẳng hạn như kiến thức về thị trường tiềm năng, phân tích nhu cầu của người dùng, vân vân

Kiểm tra chu trình nghiệp vụ dựa trên kinh nghiệm có ảnh hưởng có lợi đến tất cả các khâu của quy trình phát triển và thiết kế Đánh giá giao diện có thể ảnh hưởng đến các nghiên cứu thị trường cũng như các đầu vào liên quan của một phân tích yêu cầu người dùng

2.3.2.2.2! Định nghĩa đầu vào cho kiểm tra chu trình nghiệp vụ

Trước khi bắt đầu phân tích chu trình nghiệp vụ, ta cần phải thống nhất 4 điểm sau: 1.! Ai là người dùng của hệ thống? Ta có thể chỉ cần một mô tả chung chung chẳng hạn như “người dùng là người sử dụng các máy ATM” Tuy nhiên, đối với phương pháp kiểm tra chu trình nghiệp vụ, mô tả cần bao gồm những kinh nghiệm nền tảng hoặc kiến thức kĩ thuật có thể tác động đến người dùng khi họ sử dụng một giao diện mới Ví dụ như người dùng có thể được mô tả là “ những người sử dụng máy Macintosh và đã từng sử dụng MacPaint” Ta cũng cần xem xét kiến thức của người dùng về tác vụ họ thực hiện và giao diện họ đang sử dụng

2.! Tác vụ (hoặc những tác vụ) nào cần được phân tích? Phương pháp kiểm tra chu trình nghiệp vụ liên quan đến các phân tích chi tiết của một bộ các tác vụ Ta cũng có thể thực hiện phân tích tất cả các tác vụ quan trọng của một hệ thống với một chức năng đơn giản, chẳng hạn như một các hệ thống hướng tới người tiêu dùng dễ sử dụng Nhìn chung, đối với các hệ thống phức tạp, ta nên giới hạn các phân tích và chỉ tập trung vào một tập hợp nhỏ các tác vụ chuẩn mực làm đại diện

Một câu hỏi quan trọng được đặt ra là làm thế nào để lựa chọn được các tác vụ đại diện Việc lựa chọn các tác vụ này cần phải dựa trên các kết quả nghiên cứu thị trường, các phân tích nhu cầu người dùng, kiểm tra khái niệm, và các phân tích yêu cầu Một vài tác vụ chuẩn mực cần được lấy mẫu dựa trên chức năng chính của ứng dụng, hay nói khác đi là các thao tác cơ bản mà hệ thống hỗ trợ Hơn nữa, một số tác vụ cần được lựa chọn dựa trên việc kết hợp những chức năng cơ bản đó

Các tác vụ mẫu phải cụ thể và thực tế nhất có thể Các mô tả tác vụ phải bao gồm bối cảnh cần thiết, chẳng hạn như nội dung của các cơ sở dữ liệu mà người dùng cần sử dụng Bối cảnh này cần phản ánh các điều kiện được áp dụng cho hệ thống Chẳng hạn, trong tác vụ trích xuất cơ sở dữ liệu thì cơ sở dữ liệu lớn hay nhỏ tùy thuộc vào nhu cầu

sử dụng của hệ thống

28

Chuỗi thao tác chính xác cho mỗi tác vụ là gì và nó được mô tả ra sao? Đối với mỗi tác

vụ, ta cần phải có một mô tả về việc người dùng hiểu về tác vụ như thế nào trước khi

họ học cách sử dụng giao diện Ta cũng cần mô tả chuỗi các thao tác cần thiết để hoàn thành tác vụ Những thao tác này có thể chỉ là các dịch chuyển đơn giản, chẳng hạn như

“bấm vào nút Return” hoặc “dịch chuyển con trỏ chuột về mục File” Chúng cũng có thể là các chuỗi gồm nhiều thao tác đơn giản mà người dùng thực hiện như một thao tác đơn, chẳng hạn như thao tác “login vào hệ thống” đối với người có kinh nghiệm sử dụng UNIX, hoặc “Chọn Save từ mục File” đối với người có kinh nghiệm sử dụng Macintosh Việc quyết định xem nên chia nhỏ các thao tác đến mức độ nào là hợp lý phụ thuộc chủ yếu vào mức độ thành thạo của người dùng Thông thường, các thao tác nên được mô tả cùng mức độ chi tiết với một tài liệu hướng dẫn sử dụng hiệu quả Một tập hợp các thao tác bấm phím tương tự nhau, chẳng hạn như các thao tác cần thực hiện khi người dùng gõ vào tên file, có thể được coi như một thao tác đơn (Wharton và các tác giả khác 1992)

3.! Giao diện được định nghĩa như thế nào?

Định nghĩa của giao diện phải mô tả những gợi ý cho mỗi thao tác cần thực hiện để hoàn thành tác vụ, cũng như các phản ứng của giao diện đối với từng thao tác đó Nếu giao diện đã được cài đặt thì tất cả các thông tin đó phải có sẵn trong phần cài đặt Ở khâu sớm hơn trong quy trình phát triển, đánh giá có thể được thực hiện thông qua một

mô tả giao diện viết trên giấy Tuy nhiên, một số tính năng quan trọng của hệ thống sẽ rất khó đánh giá, chẳng hạn như thời gian phản hồi, phân biệt màu sắc, và các tương tác vật lý

Đối với mô tả trên giấy, mức độ chi tiết trong định nghĩa giao diện phụ thuộc vào mức

độ thành thạo của người dùng đối với hệ thống Ví dụ, để phân tích một ứng dụng trên máy Macintosh dành cho người dùng có kinh nghiệm với máy Mac, ta không cần cung cấp mô tả chi tiết hình dạng bên ngoài của các bảng chọn chuẩn trên máy Mac Thay vào đó, ta chỉ cần liệt kê nội dung của các bảng chọn là đủ

2.3.2.2.3! Duyệt qua các thao tác

Khâu phân tích trong phương pháp kiểm tra chu trình nghiệp vụ bao gồm kiểm tra mỗi thao tác trong chuỗi các thao tác mà người dùng cần thực hiện để hoàn thành tác vụ, và

cố gắng kể một câu chuyện đáng tin cậy trong đó vì sao người dùng nên chọn thao tác

đó Câu chuyện đó đó phụ thuộc vào các giả thiết về kiến thức nền tảng và mục tiêu của người dùng, và sự hiểu biết về quy trình giải quyết vấn đề cho phép người dùng lựa chọn được thao tác chính xác

Một cách ngắn gọn, quy trình giải quyết vấn đề diễn ra như sau:

29

(1) người dùng bắt đầu với một mô tả chung về tác vụ mà họ muốn hoàn thành,

(2) lựa chọn các thao tác để hoàn thành tác vụ (hoặc một phần tác vụ),

(3) quan sát các phản ứng của giao diện để xem các thao tác của họ có đạt được hiệu quả như mong muốn hay không,

(4) xác định thao tác nào cần thực hiện tiếp theo

Lưu ý rằng người dùng có thể áp dụng các kinh nghiệm của khi ra quyết định Cụ thể

là họ thường sử dụng chiến thuật “dựa theo nhãn” để lựa chọn thao tác cần thực hiện nếu như nhãn gắn với thao tác đó khớp với mô tả của tác vụ (Engebeck 1986) Chẳng hạn một người dùng cần thực hiện tác vụ “in tài liệu” có thể chọn thao tác được gán nhãn “in” hoặc “tài liệu” (hoặc có biểu tượng chiếc máy in hoặc tài liệu)

Các tính năng quan trọng của giao diện cần phải có mối liên kết giữa mô tả tác vụ người dùng và thao tác đúng, cũng như cung cấp các thông tin phản hồi cho thấy tiến độ mà người dùng đạt được Khi tiến hành kiểm tra chu trình nghiệp vụ, người phân tích đặt

ra 4 câu hỏi sau:

1.! Liệu người dùng có đạt được kết quả như mong muốn? (chẳng hạn, tác vụ của người dùng có thể là in tài liệu, nhưng điều đầu tiên người đó cần làm là chọn một máy in Vậy liệu người đó có biết rằng họ cần phải chọn máy in không?) 2.! Liệu người dùng có biết cách thực hiện thao tác đúng hay không? (Nếu thao tác

đó là lựa chọn từ một bảng chọn nhìn thấy rõ rệt thì sẽ không có vấn đề gì Nhưng nếu thao tác đó là việc phải bấm chuột 3 lần vào biểu tượng máy in, thì người dùng có thể không nghĩ đến điều đó)

3.! Liệu người dùng có kết nối thao tác đúng với kết quả mà họ cần đạt được hay không?

4.! Nếu thao tác đúng được thực hiện thì liệu người dùng có thấy được tiến độ hoàn thành tác vụ của mình không? (chẳng hạn như sau khi chọn máy in, hộp thoại hiển thị “Máy in laser ở phòng 105” cho thấy rõ rằng người dùng đã chọn được máy in Trường hợp xấu nhất xảy ra là khi không có phản hồi nào từ phía giao diện)

Những câu hỏi này là các hướng dẫn không rõ ràng Tuy nhiên ý nghĩa của chúng sẽ rõ hơn trong bối cảnh cụ thể Cũng cần nhấn mạnh rằng 4 câu hỏi trên không phải là yêu cầu tuyệt đối Chúng là các tiêu chuẩn mà người phân tích cần xem xét để tạo ra một câu chuyện đáng tin cậy nhằm giải thích sự tương tác giữa người dùng và giao diện

2.3.2.2.4! Nắm bắt thông tin quan trọng trong quá trình đánh giá

Trong quá trình đánh giá, việc nắm bắt các thông tin cho phép nhóm thực hiện đánh giá

Có một vài dạng thông tin hữu ích mà ta cần nắm bắt được trong quá trình đánh giá Đó

là các yêu cầu về kiến thức người dùng, các giả thiết về mật độ người dùng, các chú thích về các vấn đề bên lề và những thay đổi thiết kế, và câu chuyện đáng tin cậy được phát triển qua việc kiểm tra chu trình nghiệp vụ

Đối với thông tin người dùng, ta cần nắm bắt những thông tin sau đây với mỗi phân lớp người dùng:

o! Thông tin nào người dùng cần biết trước để thực hiện tác vụ

o! Thông tin nào người dùng cần phải học khi thực hiện tác vụ

Đối với các vấn đề bên lề và các thay đổi thiết kế được bàn đến trong quá trình đánh giá, ta cần chú thích lại các vấn đề cụ thể cùng với ngữ cảnh phù hợp và đầy đủ để sau

đó ta có thể khôi phục và xử lý vấn đề một cách triệt để Chẳng hạn, trong quá trình đánh giá một thao tác cụ thể nào đó, ta nhận thấy có một mục đơn viết sai chính tả Ta cần ghi lại mục đơn này để sau đó ta có thể xác định được vị trí của vấn đề và sửa lại Băng video ghi lại quá trình đánh giá cũng có thể được sử dụng trong trường hợp này

2.3.2.3! Phạm vi và những giới hạn của phương pháp

Kiểm tra chu trình nghiệp vụ dựa trên kinh nghiệm chỉ tập trung vào một thuộc tính của khả năng sử dụng, đó là tính dễ học Lý thuyết về tiếp nhận kĩ năng (chẳng hạn như Anderson 1987) dự đoán rằng trợ giúp học thông qua phương pháp thăm dò sẽ giúp cho việc tiếp nhận kĩ năng trở nên dễ dàng Các thuộc tính khác của khả năng sử dụng, ví

dụ như chức năng và tính dễ sử dụng, có mối liên hệ qua lại với tính dễ học Chẳng hạn, nếu chức năng của một ứng dụng không khớp với nhu cầu của người dùng, và người đó cần phải thực hiện một chuỗi các thao tác để hoàn thành tác vụ của mình, thì việc học cách sử dụng hệ thống đó là rất khó khăn

Kiểm tra chu trình nghiệp vụ dựa trên kinh nghiệm cho phép đánh giá mỗi bước cần thiết để thực hiện một tác vụ, đồng thời phát hiện các lỗi thiết kế có ảnh hưởng đến quá trình học bằng cách thăm dò Phương pháp này nhằm tìm ra sự không ăn khớp giữa khái niệm về tác vụ của người sử dụng và những người thiết kế, tiêu đề không phù hợp trên