Đánh giá thiết kế giao diện docx

 Những điểm sau đây cần được người thiết kế quan tâm:  Sự hoàn hảo là không thể trong hệ thống phức tạp, do đó, kế hoạch phải bao gồm các phương pháp để tiếp tục sửa chữa các

Đánh giá thiết kế giao diện

 Chương 4 - DTUI

2

 Nhiều yếu tố quyết định kế hoạc đánh giá:

 Giai đoạn thiết kế, sự quan trọng, chi phí, thời gian, kinh nghiệm

…

 Phạm vi của các kế hoạch đánh giá có thể đến từ một

tham vọng thử nghiệm 2 năm tới một vài ngày thử

nghiệm

 Phạm vi chi phí có thể từ 20% xuống tới 5% của dự án

► Mở đầu

 Một khía cạnh đáng lo ngại là sự không chắc chắn còn

tồn tại kể cả sau khi đã kiểm tra toàn bộ

 Những điểm sau đây cần được người thiết kế quan tâm:

 Sự hoàn hảo là không thể trong hệ thống phức tạp, do đó, kế

hoạch phải bao gồm các phương pháp để tiếp tục sửa chữa các vấn đề trong suốt vòng đời của một giao

 Tại một số điểm quyết định đã được thực hiện về kiểm tra toàn

diện nguyên mẫu và phân phối các sản phẩm

 Hầu hết các phương pháp kiểm tra thích hợp cho việc sử dụng

bình thường, phát huy hiệu quả trong các tình huống không thể dự đoán trước.

Đánh giá, kiểm thử

 Là phương pháp kiểm tra kép, tìm kiếm các lỗi có thể đối với chương trình, giao diện.

 Kiểm tra về tài nguyên của chương trình, các lỗi,

khả năng khắc phục (khôi phục sau khi lỗi)

 Kiểm tra về hiệu suất, khả năng đáp ứng của

chương trình với một lượng người dùng, các kết

nối có thể có đối với chương trình

 Kiểm tra tính sử dụng, thông qua các nhóm

người sử dụng khác nhau, các vai trò của người

dùng, chuyên môn

5

 Tính sử dụng được thể hiện thông qua các câu

hỏi như về số lượng và chất lượng (ví dụ như về

số lượng dữ liệu, chất lượng cung cấp dữ liệu)

6

Ví dụ

7

Ví dụ khả năng phân chia các hình thức test

8

Nhận xét chuyên môn

 Trong khi demo chính thức cho đồng nghiệp hoặc khách hàng có thể cung cấp một số thông tin phản hồi hữu ích, nhiều đánh giá chuyên môn chính thức đã được chứng minh là có hiệu quả

 Kết quả có thể là một báo cáo chính thức với những vấn

đề được xác định hoặc kiến nghị đối với các thay đổi

 Ngoài ra, việc xem xét có thể dẫn đến một cuộc thảo luận hay trình bày để thiết kế hoặc quản lý

 Nhận xét chuyên môn chiếm effort từ nửa ngày đến một tuần

 mặc dù một thời gian đào tạo dài đôi khi có thể phải giải thích các công việc chính hoặc thủ tục hoạt động

 Đánh giá chuyên môn có thể được lập kế hoạch tại một

số điểm trong quá trình phát triển

► Nhận xét chuyên môn

 Có nhiều phương pháp để xem xét chuyên môn

từ lựa chọn:

 Đánh giá thông qua khám phá

 Xem xét các nguyên tắc

 Kiểm tra tính nhất quán

 Định hướng nhận thức

 Kiểm tra khả năng sử dụng

Nhận xét chuyên môn: thông qua khám phá

 Phê phán một giao diện để xác định sự phù hợp với một

danh sách ngắn của nguyên tắc thiết kế, như thông qua 8 luật vàng

 Các chuyên gia phải quen thuộc với các quy tắc và có thể giải thích và áp dụng chúng

 Ví dụ (Nielsen’s heuristics):

 “Công nhận hơn là thu hồi”

 Là các đối tượng, hành động và các tùy chọn luôn luôn nhìn thấy được?

 “Tính linh hoạt và hiệu quả sử dụng”

 Có sự rút gọn đã được cung cấp cho phép người dùng có kinh nghiệm để thực hiện nhiệm vụ nhanh chóng hơn?

Nhận xét chuyên môn: xem xét các nguyên

tắc

 Giao diện đã được kiểm tra cho phù

hợp với sự tổ chức hoặc các tài liệu

hướng dẫn

 Bởi vì các văn bản hướng dẫn có thể

có hàng trăm mục, có thể mất một

thời gian dài để làm chủ các nguyên

tắc và xem lại giao diện

Nhận xét chuyên môn: Kiểm tra tính nhất

quán

 Các chuyên gia xác minh tính nhất quán trên

một họ giao diện và tài liệu trợ giúp

 Kiểm tra đối với thuật ngữ, phông chữ, phối

màu, bố trí, định dạng đầu vào/đầu ra, vv

 Một bản in màn hình đã được chứng minh là có

hiệu quả trong việc phát hiện mâu thuẫn và bất

thường của các mẫu

Định hướng nhận thức

 Các chuyên gia mô phỏng người sử dụng

thông qua giao diện theo các kịch bản cụ

 người dùng sẽ biết phải làm gì,

 xem làm thế nào để làm điều đó, và

 hiểu các phản hồi hay hành động là đúng hay

không?

Kiểm tra khả năng sử dụng

 Các chuyên gia tổ chức một cuộc họp đánh giá,

với người trung gian, mô tả giao diện và thảo

luận về điểm mạnh và điểm yếu của nó Nhóm

thiết có thể đưa ra bằng chứng về các vấn đề

trong một định dạng đối lập.

 Có thể truyền đạt kinh nghiệm cho các nhà thiết

kế giỏi, nhưng họ có thể mất lâu hơn để chuẩn bị

 Hiếm khi được so sánh với các phương pháp

đánh giá khác.

Phương pháp

 Xác định nhóm người dùng tham gia kiểm tra dựa trên

các tính năng của sản phẩm (như sản phẩm thực, mẫu

sản phẩm và thông qua simulator)

 Xác định sự phản hồi của người dùng như qua interview,

đánh giá điểm sử dụng các chức năng (khảo sát)

 Xác định khả năng tương tác giữa người dùng với

chương trình, thông qua các nhóm riêng biệt, sử dụng

PTN …

 Thông qua số lượng kết quả, đưa ra tính sử dụng bằng

bảng hoặc biểu đồ

16

Ví dụ dưới dạng kết quả biểu đồ kiểm tra

17

Kiểm tra những gì?

 Kiểm tra dựa trên hồi quy

 So sánh kết quả của các lần kiểm tra trước với các lần trước nữa hoặc

với các dữ liệu đã được biết trước

 Chắc chắn lỗi đã được sửa

 Có thể chạy kiểm tra hồi quy để đảm bảo các chức năng hoạt động tốt,

toàn bộ hệ thống con/chức năng con, tính năng của chương trình

 Kiểm tra dữ liệu

 Kiểu dữ liệu, xử lý các dữ liệu thực

 Tổng hợp các dữ liệu liên quan (dữ liệu thực, dữ liệu thống kê …)

 Đưa ra sự thống kê lỗi liên quan

 Kiểm tra giao diện

Kiểm tra khả năng sử dụng và thí nghiệm

 Sự cần thiết của kiểm tra khả năng sử dụng và thí nghiệm từ đầu những năm 80

 Hướng tới kiểm tra khả năng sử dụng nhằm kích thích

việc xây dựng PTN về khả năng sử dụng

 Mô hình của PTN là có 2 diện tích khoảng 10x10 foot,một dành cho thử nghiệm sự hoạt động, và cái khác dành cho các kiểm tra và quan sát

 Nhân viên của PTN có kinh nghiệm trong kiểm thử và

thiết kế giao diện người dùng

 Họ có thể phục vụ cho nhiều dự án trong năm

 Họ giúp người thiết kế tạo kế hoạch kiểm thử và thực

hiện kiểm tra thí điểm một tuần trước khi có sự kiểm tra thực sự

► Kiểm tra khả năng sử dụng và thí nghiệm

 Những người tham gia nên được chọn để đại diện cho

cộng đồng người sử dụng dự định,

 với kiến thức nền tảng về máy tính, kinh nghiệm với các bài toán, giáo dục, và khả năng với các ngôn ngữ tự nhiên được sử dụng

trong giao

 Những người tham gia phải được đối xử với sự tôn trọng

và cần được thông báo rằng họ không phải là những

người mà đang được thử nghiệm; mà thay vào đó, họ

tham gia vào kiểm tra giao diện

 Họ cần được nói về những gì họ sẽ làm và trong bao lâu

 Sự đồng ý tham gia nên luôn luôn tự nguyện, và thông

báo về thông tin cần được thu

► Kiểm tra khả năng sử dụng và thí nghiệm

 Tư duy rõ ràng thường dẫn tới nhiều đề nghị để cải tiến

 Quay video những người tham gia thực hiện nhiệm vụ để có giá trị

xem xét và sau đó cho các nhà thiết kế hoặc quản lý thấy những vấn

đề mà người dùng gặp phải

 Rất nhiều các hình thức của thử nghiệm khả năng sử dụng:

 Mô hình giấy

 Giảm khả năng kiểm tra khả năng sử dụng

 Tính cạnh tranh

 Tính toàn diện

 Môi trường kiểm tra và thí nghiệm di dộng

 Kiểm tra tính sử dụng từ xa

► Kiểm tra tính sử dụng và thí nghiệm

 Mô hình giấy

 Nó được thực hiện bằng cách sử dụng mô hình trên

giấy để đánh giá phản ứng của người sử dụng từ ngữ,

bố trí, và trình tự

 Một quản trị viên kiểm tra đóng vai trò của máy tính

bằng cách lật các trang trong khi yêu cầu một người

sử dụng tham gia thực hiện bài toán

 Đây là thử nghiệm chính thức không tốn kém, nhanh

chóng, và hiệu quả

 Tốt trong giai đoạn đầu của thiết kế

Ví dụ

23

► Kiểm tra tính sử dụng và thí nghiệm

 Tối thiểu hóa kiểm tra tính sử dụng

 Tiếp cận nhanh, ảnh hượng rộng rãi

 Có từ 3 đến 6 người tham gia kiểm tra

 Ủng hộ nói tất cả các vấn đề nghiêm trọng được tìm tháy với một số thành viên

 Phên bình nói rằng nhiều thành viên là cần thiết để kiểm tra các hệ thống phức tạp hơn

 Nên được sử dụng như là một đánh giá hình thành không phải là đánh giá tổng kết

 Hình thành đánh giá: Thông qua quá trình thiết kế; nhận ra các vấn đề để có hướng thiết kế lại

 Tổng kết đánh giá: Gần cuối của quá trình thiết kế; cung cấp thông tin cho sự hình thành sản phẩm

► Kiểm tra tính sử dụng và thí nghiệm

 Tính cạnh tranh

 So sánh một giao diện mới với phiên bản trước đó

hoặc sản phẩm tương tự từ các đối thủ cạnh tranh

 Cần được chú ý để xây dựng song song với các nhiệm

vụ và để cân bằng thứ tự thể hiện của các giao diện

 Ít người tham gia là cần thiết, mặc dù chiếm khoảng

thời gian lâu hơn

► Kiểm tra tính sử dụng và thí nghiệm

 Tính toàn diện

 Kiểm tra giao diện với các người dụng da dạng khác

nhau, nền tảng phần cứng, phần mềm và mạng

 Thử nghiệm với sự nâng cao tỷ lệ thành công của

khách hàng:

 Hiển thị nhỏ và lớn

 Mạng chậm và nhanh

 Các hệ điều hành và trinh duyệt khác nhau

 Lĩnh vực kiểm tra và thí nghiệm động

 Đưa giao diện mới vào môi trường thực tế với thời

gian kiểm tra cố định

 Nó hiệu quả trong việc phát hiện ra lỗi, câu lệnh và

giúp tăng hiệu xuất

 Sự kiểm tra động với việc ghi hình và liên kết đã phát

triển

 Một loại khác nhau của lĩnh vực thử nghiệm nhằm

cung cấp cho người sử dụng với các phiên bản thử

nghiệm mới của phần mềm hoặc sản phẩm tiêu dùng;

hàng chục hoặc thậm chí hàng ngàn người sử dụng có thể nhận được phiên bản beta và được yêu cầu bình

luận

► Kiểm tra tính sử dụng và thí nghiệm

► Kiểm tra tính sử dụng và thí nghiệm

 Kiểm tra từ xa

 Kiểm tra online

 Không cần thiết đưa thành viên tới PTN

 Có thể với số lượng thành viên lớn với các kiến thức

khác nhau

 Tác động trực tiếp vào thực tế

 Ít kiểm soát hành vi người dùng và ít cơ hội để quan

sát phản ứng của họ

 Sử dụng log được cho là hữu ích

► Kiểm tra tính sử dụng và thí nghiệm

 Giới hạn

 Nhấn mạnh tới việc tính sử dụng ban đầu

 Không ước lượng được hiệu xuất làm việc như thế nào sau một tuần hoặc một tháng

 Nó giới hạn các tính năng của giao diện

 Một chiến lược tốt:

 Kiểm tra tính sử dụng + chuyên gia đánh giá

Khảo sát

 Khảo sát người dùng là sự tiện lợi, ít tốn kém

và nói chung được chấp nhận để thử nghiệm

khả năng sử dụng và đánh giá chuyên gia

 Số người lớn được hỏi đưa ra nhận xét so

sánh với các khả năng đánh giả của số lượng

nhỏ người tham gia khả năng sử dụng hoặc

chuyên gia nhận xét.

 Chìa khóa của thành công

 Mục tiêu rõ ràng

 Phát triển tập trung vào một số vấn đề giúp

đạt được mục tiêu

► Khảo sát

 Mục tiêu khảo sát cần yêu cầu người sử dụng có

 Trạng thái chung(tuổi, giới tính, thành phần, giáo dục …)

 Kinh nghiệm với máy tính (đặc biệt là là với gói phần mềm,

thời lượng, sự hiểu biết)

 Trách nhiệm công việc (ra quyết định, vai trò quản lý)

 Lý do không sử dụng giao diện (không đầy đủ, quá phức tạp,

quá chậm)

 Làm quen với các tính năng (in ấn, macro, các phím tắt,

hướng dẫn)

 Cảm nhận sau khi sử dụng giao diện (nhầm lẫn vs rõ ràng,

thất vọng vs trong kiểm soát, buồn tẻ vs thú vị)

► Khảo sát

 Khảo sát online giúp tránh chi phí in ấn, các vấn đề ko

cần thiết thông qua phân phát và sưu tập form giấy

 Nhiều người thích trả lời một cuộc điều tra ngắn hiển

thị trên màn hình, thay vì phải điền vào và trả lại một

Acceptance Test

 Đối với việc thực hiện các dự án lớn, các khách hàng

hoặc người quản lý thường đặt ra mục tiêu và thước đo cho phần cứng và phần mềm

 Nếu các sản phẩm hoàn thành không đáp ứng các tiêu

chí này, hệ thống này phải được làm lại cho đến khi

thành công

 Thay vì các tiêu chuẩn mơ hồ và sai lầm của "người

dùng thân thiện", thước đo chuẩn cho các giao diện

người dùng có thể được thành lập để sau đây:

 Thời gian để tìm hiểu các chức năng cụ thể

 Tốc độ thực hiện nhiệm vụ

 Tỷ lệ lỗi của người sử dụng

 Con người chú ý lưu các lệnh theo thời gian

 Làm hài lòng người sử dụng

► Acceptance Test

 Trong một hệ thống lớn, có thể có 8 hoặc 10 test để thực

hiện trên các thành phần khác nhau của giao diện và với

các cộng đồng người sử dụng khác nhau

 Do có thể khác nhau về môi trường, các tổ chức test bên

ngoài phải đảm bảo trung lập

 Mục tiêu trọng tâm không phải là để phát hiện sai sót, mà

là để xác minh sự tuân thủ các yêu cầu

 Một khi thử nghiệm chấp nhận (Acceptance test) đã

thành công, có thể có một khoảng thời gian thử nghiệm

trước khi phân phối sản phẩm

Thực hiện acceptance test

 Nằm tại tầng Business – Facing trong sơ đồ tại slide 8

 Có sự tham gia của khách hàng/người dùng trong việc

kiểm tra sản phẩm có đúng với yêu cầu hay không

 Mục tiêu cần phải được viết trước khi phát triển chương

trình

 Mục tiêu test phải được viết bởi khách hàng hoặc người

dùng

 Nhóm phát triển cần trả lời được: Làm sao tôi biết được

khi nào thì tôi làm xong

 Khách hàng/người dùng phải trả lời được: Tôi đã thấy hết được những cái tôi cần trong chương trình chưa

 Chương trình cần phải được chạy như là sản phẩm thực

Ví dụ

36

Phần tự đọc

Các phần sau sinh viên tự đọc, tóm tắt và làm bài tập sau chương này:

 4.6 Evaluation During Active Use

 4.7 Controlled Psychologically Oriented Experiments