Một bài học tương tác mở được trên máy của người biên soạn nhưng đưa lên hệ thống học tập lại không ghi nhận điểm. Có khi người học đã hoàn thành mà hệ thống vẫn báo chưa xong. Những vấn đề này cho thấy cần phân biệt nội dung học với cách nội dung giao tiếp cùng nền tảng.
SCORM là một khái niệm thường gặp ở bước xuất và triển khai học liệu. Người dạy không nhất thiết phải đọc toàn bộ đặc tả để bắt đầu, nhưng cần hiểu nó giải quyết việc gì, không giải quyết việc gì và cần kiểm thử những trạng thái nào. Bài viết tập trung vào các quyết định thực hành trước khi giao bài cho sinh viên.
1. Hiểu SCORM qua việc kết nối học liệu với hệ thống
SCORM là viết tắt của Sharable Content Object Reference Model. Theo ADL, đây là một tập hợp tiêu chuẩn và đặc tả kĩ thuật giúp nội dung học tập và các sản phẩm phù hợp cùng phiên bản có thể tương tác với nhau. Phạm vi gồm gói nội dung, đối tượng nội dung có thể chia sẻ và môi trường quản lí học tập (ADL, 2009).
Có thể hình dung gói học liệu là một sản phẩm có tài nguyên và thông tin tổ chức; LMS là nơi phân phối và quản lí. Việc học liệu hiển thị và việc kết quả được truyền đúng là hai vấn đề liên quan nhưng khác nhau. Khi kiểm thử, cần xem cả hai.
SCORM không phải phương pháp dạy học. Một gói được hệ thống chấp nhận có thể vẫn chứa câu hỏi mơ hồ hoặc hoạt động chưa phù hợp. Tính đúng về kĩ thuật giúp triển khai; chất lượng sư phạm cần được thiết kế và đánh giá bằng tiêu chí riêng.
2. Khi nào nhu cầu của bạn liên quan đến SCORM?
Trước hết, hỏi mình có cần học liệu gửi trạng thái hay kết quả về LMS không. Nếu chỉ cung cấp một video để xem lại, nhu cầu có thể khác với một bài tương tác cần theo dõi tiến độ. Nếu đang xây bài kiểm tra, cần làm rõ điểm được tính ở đâu và nơi nào lưu kết quả chính thức.
Một phương án thiết kế có thể dùng công cụ biên soạn để tạo hoạt động, rồi xuất gói cho LMS. Tuy nhiên, đừng chọn một định dạng chỉ vì tên thường xuất hiện trong hướng dẫn. Cần xem công cụ và hệ thống thực tế hỗ trợ gì, cùng yêu cầu của đơn vị sử dụng.
Trong tài liệu ActivePresenter, các lựa chọn HTML5, SCORM và xAPI được mô tả trong nhóm đầu ra tương tác, với phạm vi phụ thuộc phiên bản sử dụng. Điều này là một căn cứ để kiểm tra khả năng của công cụ, không phải bảo đảm mọi cấu hình LMS đều vận hành giống nhau (Atomi Systems, User Manual).
3. Làm rõ “hoàn thành” và “đạt” trước khi xuất
Người thiết kế cần định nghĩa thế nào là hoàn thành nhiệm vụ và thế nào là đạt yêu cầu. Xem hết các màn hình có thể là một điều kiện hoàn thành, nhưng chưa thể coi là minh chứng hiểu nội dung. Đạt một mức điểm cũng cần xét câu hỏi có đo mục tiêu phù hợp không.
Giả sử bài học có phần đọc và ba nhiệm vụ. Nếu người học bỏ qua nhiệm vụ cuối nhưng đã mở mọi màn hình, bạn muốn hệ thống báo trạng thái gì? Nếu làm đúng sau nhiều lần nhận phản hồi, điểm cuối nên được hiểu như kết quả luyện tập hay kết quả đánh giá? Các quyết định này cần có trước cấu hình.
Viết quy tắc bằng ngôn ngữ người học hiểu được. Sau đó đối chiếu quy tắc với thiết lập của công cụ xuất và LMS. Một cấu hình tự động không có nghĩa đã phù hợp với chính sách đánh giá của học phần.
4. Xác định phiên bản và môi trường triển khai
Không nên nói chung rằng “hệ thống hỗ trợ SCORM” rồi bỏ qua phiên bản. ADL nêu tính tương tác giữa nội dung và LMS phù hợp cùng phiên bản. Người biên soạn cần kiểm tra tài liệu của hệ thống đang dùng và thử bằng chính môi trường dự kiến triển khai.
Một tệp mẫu giúp kiểm tra sớm hơn cả chương học liệu. Hãy tạo sản phẩm nhỏ có một nhiệm vụ, một phản hồi và một cách kết thúc. Nếu các trạng thái chưa được ghi nhận đúng, hãy giải quyết trước khi nhân rộng cấu trúc sang nhiều bài.
Việc chạy thành công trên một hệ thống thử không thay thế kiểm tra trên hệ thống thật. Các thiết lập của khóa học, trình duyệt và tài khoản có thể ảnh hưởng trải nghiệm. Ghi lại môi trường đã thử để khi phát sinh lỗi, nhóm có dữ kiện đối chiếu.
5. Kiểm thử bằng tài khoản học viên
Tài khoản người biên soạn thường có quyền và cách truy cập khác người học. Vì vậy, cần thực hiện một lượt từ góc nhìn học viên. Mở bài theo đường dẫn trong khóa học, làm đúng và làm sai, thoát giữa chừng rồi quay lại, hoàn thành và xem báo cáo.
Đừng chỉ kiểm tra trường hợp thuận lợi nhất. Nếu sinh viên đóng cửa sổ khi chưa kết thúc, điều gì được lưu? Nếu làm lại, hệ thống hiển thị lượt nào? Nếu thiết bị khác, chữ và nút có dùng được không? Mỗi câu hỏi cần một kết quả quan sát, không chỉ dự đoán của người thiết kế.
| Tình huống thử | Điều cần quan sát | Cách ghi nhận |
|---|---|---|
| Mở bài lần đầu | Tài nguyên và hướng dẫn | Ảnh hoặc ghi chú |
| Trả lời sai | Phản hồi và điểm | So với quy tắc |
| Thoát rồi quay lại | Tiến độ và vị trí | Kiểm tra trên LMS |
| Hoàn thành | Trạng thái cuối | Đối chiếu báo cáo |
| Làm lại | Kết quả được giữ | Xem chính sách lượt |
Bảng này là đề xuất kiểm thử cho người biên soạn, không phải danh sách chứng nhận SCORM. Khi cần đánh giá tuân thủ kĩ thuật, phải sử dụng yêu cầu và phương tiện phù hợp với đặc tả áp dụng.
6. Phân biệt lỗi nội dung với lỗi triển khai
Nếu người học không trả lời được vì câu dẫn khó hiểu, đó là vấn đề thiết kế nội dung. Nếu đã trả lời nhưng điểm không được ghi đúng, cần xem thiết lập và giao tiếp với hệ thống. Gộp hai loại lỗi có thể khiến nhóm sửa nhầm chỗ.
Khi báo lỗi, ghi thao tác dẫn đến lỗi, trạng thái mong muốn, trạng thái thực tế và môi trường. Chẳng hạn: tài khoản học viên, trình duyệt, bài đã làm ở lượt nào và điểm hiển thị tại đâu. Những thông tin này hữu ích hơn câu “gói không chạy”.
Giữ một bản nguồn của học liệu bên cạnh gói đã xuất. Khi sửa, ghi phiên bản và ngày. Nếu chỉ giữ tệp phát hành, việc cập nhật câu hỏi hoặc tái xuất có thể khó hơn, đặc biệt khi nhiều người cùng tham gia.
7. Chuẩn bị người học và hỗ trợ trong khóa học
Hướng dẫn nên nói rõ cách mở bài, cách kết thúc, điều kiện hoàn thành và nơi tìm trợ giúp. Nếu có yêu cầu thiết bị hoặc trình duyệt đã kiểm thử, hãy trình bày dễ hiểu. Người học không cần đọc các thuật ngữ kĩ thuật để biết mình phải làm gì.
Đặt nhiệm vụ trong cấu trúc của học phần. Trước bài, sinh viên cần kiến thức gì? Sau bài, họ sẽ dùng kết quả ở đâu? Một gói hoạt động tốt vẫn cần được nối với thảo luận, thực hành hoặc phản hồi của người dạy khi mục tiêu đòi hỏi.
Hãy chuẩn bị phương án cho trường hợp khó truy cập. Có thể là tài liệu thay thế hoặc cách nộp sản phẩm khác, tùy nhiệm vụ và quy định của học phần. Mục đích là giúp sinh viên đạt mục tiêu, không biến một lỗi kĩ thuật thành trở ngại không có đường xử lí.
8. Bắt đầu từ một bài học có thể bảo trì
Một quy trình vừa sức là xác định mục tiêu, viết kịch bản, dựng bản thử, kiểm tra nội dung, kiểm thử LMS rồi triển khai. Sau khi người học sử dụng, ghi lỗi và phản hồi để quyết định điều chỉnh. Đừng chờ hoàn thành cả khóa mới phát hiện quy tắc điểm chưa phù hợp.
Tính công sức cập nhật ngay từ đầu: ai sửa nguồn, ai xuất, ai kiểm tra và ai xác nhận bản đang dùng. Một biểu mẫu bàn giao ngắn giúp giữ các vai trò rõ. Đây là một lựa chọn quản lí công việc, không phải yêu cầu bắt buộc của mọi đặc tả.
SCORM có giá trị khi đáp ứng nhu cầu kết nối học liệu với hệ thống. Quyết định sử dụng vẫn nên bắt đầu từ hoạt động học và loại thông tin cần theo dõi. Sau khi đã rõ nhu cầu, kiểm thử thực tế sẽ giúp xác nhận lựa chọn.
5 ý chính cần nhớ
- SCORM hỗ trợ tương tác kĩ thuật giữa nội dung và LMS phù hợp.
- Chất lượng sư phạm cần tiêu chí riêng ngoài khả năng chạy gói.
- Định nghĩa hoàn thành, đạt và làm lại trước khi cấu hình.
- Kiểm thử bằng tài khoản học viên trên môi trường thật.
- Lưu nguồn, phiên bản và quy trình cập nhật để bảo trì.
Tài liệu tham khảo
- Advanced Distributed Learning. (2009). SCORM 2004 4th Edition Testing Requirements, phiên bản 1.1. Đặc tả chính thức.
- Advanced Distributed Learning. Guidelines for Creating Reusable Content with SCORM 2004. Hướng dẫn.
- Atomi Systems. ActivePresenter 10 User Manual. Tài liệu công cụ.
Đọc tiếp
- EdTech trong giáo dục đại học
- ActivePresenter có thể làm gì cho bài giảng E-learning?
- AI trong giảng dạy
Hãy thử một gói nhỏ và ghi kết quả của năm tình huống trong bảng trước khi triển khai cả khóa. Xem tài nguyên EdTech để tiếp tục xây dựng học liệu có thể kiểm tra và duy trì.
