Phương pháp tổ chức hoạt động giải quyết vấn đề với sự hỗ trợ của máy tính trong dạy học Tin học
LỜI NÓI ĐẦU
Tổ chức hoạt động giải quyết vấn đề là một trong những nhiệm vụ trung tâm và đặc thù nhất của người giáo viên Tin học. Khác với nhiều môn học khác, Tin học lấy việc giải quyết vấn đề với sự trợ giúp của máy tính làm mạch nội dung xuyên suốt — từ lập trình, thiết kế cơ sở dữ liệu, đến khai thác ứng dụng và tìm hiểu trí tuệ nhân tạo. Vì vậy, năng lực tổ chức và dẫn dắt học sinh trong quá trình giải quyết vấn đề không phải là một kỹ năng bổ trợ mà là năng lực nghề nghiệp cốt lõi của giáo viên Tin học.
Tài liệu Phương pháp tổ chức hoạt động giải quyết vấn đề với sự hỗ trợ của máy tính trong dạy học Tin học, được biên soạn dành cho sinh viên năm thứ ba ngành Sư phạm Tin học, Khoa Tin học — Trường Đại học Sư phạm Huế.
Tiền thân của tài liệu này là chuyên đề Dạy giải bài tập Tin học — một chuyên đề tập trung cung cấp cho sinh viên tri thức về dạy giải bài tập lập trình ở trường phổ thông, với trọng tâm là các bài tập lập trình cấu trúc và thuật toán cơ bản. Qua thực tiễn giảng dạy và trước yêu cầu đổi mới của Chương trình Giáo dục phổ thông 2018 (CT GDPT 2018) môn Tin học, chuyên đề đó đã được phát triển toàn diện thành học phần hiện tại với hai hướng mở rộng quan trọng.
Thứ nhất, khái niệm bài tập Tin học được mở rộng đáng kể. Nếu trước đây trọng tâm chỉ là bài tập lập trình, thì nay tài liệu bao quát đầy đủ tám nhóm bài tập đặc thù của môn Tin học: bài tập khái niệm, thuật toán, lập trình, dữ liệu, cơ sở dữ liệu, trí tuệ nhân tạo, mạng máy tính và Web — phù hợp với sự mở rộng nội dung của CT GDPT 2018.
Thứ hai, đơn vị tổ chức dạy học không còn dừng lại ở "dạy giải bài tập" theo nghĩa truyền thống mà được nâng lên thành tổ chức hoạt động giải quyết vấn đề — một quá trình học tập trọn vẹn gồm tám bước: đọc đề, phân tích, mô hình hóa, lập kế hoạch, thực hiện, kiểm tra, đánh giá và khái quát hóa. Sự chuyển dịch này phản ánh đúng tinh thần phát triển năng lực và tư duy tính toán mà chương trình hiện hành đặt ra.
Tài liệu được tổ chức thành năm chương có tính liên thông chặt chẽ:
Chương 1 — Cơ sở lý luận về tổ chức hoạt động giải quyết vấn đề trong dạy học Tin học (4 tiết) xây dựng nền tảng lý luận: khái niệm vấn đề và giải quyết vấn đề, các mức độ vấn đề, vai trò của bài tập trong dạy học Tin học, tư duy tính toán, và ba mô hình giải quyết vấn đề: Polya, IDEAL và Design Thinking.
Chương 2 — Phân tích bài tập Tin học dưới góc nhìn phát triển năng lực (6 tiết) trang bị kỹ năng phân tích bài tập theo tám nhóm nội dung và theo bảy chiều mục tiêu: kiến thức, kỹ năng, năng lực, tư duy tính toán, mức độ Bloom, lỗi sai thường gặp và khả năng sử dụng AI.
Chương 3 — Thiết kế hoạt động giải quyết vấn đề trong dạy học Tin học (8 tiết) hướng dẫn thiết kế tình huống có vấn đề, hệ thống bài tập, câu hỏi gợi mở, scaffold, worksheet, hoạt động nhóm và phân hóa học sinh — là chương có khối lượng thực hành lớn nhất học phần.
Chương 4 — Tổ chức và hỗ trợ học sinh giải quyết vấn đề (6 tiết) đi vào thực tiễn tổ chức giờ học: phát hiện khó khăn, các kỹ thuật hỗ trợ (debugging, questioning, pair programming, peer learning, tranh luận kỹ thuật), các hình thức tổ chức học tập và năm kỹ thuật dạy học đặc thù trong giờ giải quyết vấn đề.
Chương 5 — Đánh giá hoạt động giải quyết vấn đề trong dạy học Tin học (6 tiết) trình bày hệ thống đánh giá theo sáu chiều (quá trình, sản phẩm, chiến lược giải quyết vấn đề, tư duy tính toán, hợp tác và AI Literacy) và hướng dẫn thiết kế năm công cụ đánh giá: rubric, checklist, portfolio, nhật ký học tập và AI log.
Một trong những điểm mới quan trọng của tài liệu là việc đưa trí tuệ nhân tạo (AI) vào như một chủ đề tích hợp xuyên suốt, không phải một chương độc lập. Thực tiễn cho thấy học sinh ngày nay đã và đang sử dụng các công cụ AI tạo sinh trong quá trình làm bài — đây là thực tế không thể phủ nhận và không nên né tránh. Tài liệu tiếp cận vấn đề này từ hai phía: một mặt, hướng dẫn giáo viên phân tích và xác định bước nào trong quy trình giải quyết vấn đề nên và không nên để học sinh dùng AI, từ đó thiết kế hoạt động học tập phù hợp; mặt khác, trang bị cho sinh viên kỹ năng sử dụng AI như một trợ lý thiết kế bài giảng, tạo scaffold, sinh câu hỏi gợi mở và xây dựng công cụ đánh giá. Đặc biệt, khái niệm AI Literacy — khả năng hiểu, sử dụng, phản biện và chịu trách nhiệm với output AI — được coi là một mục tiêu học tập mới cần được đánh giá một cách có hệ thống.
Tài liệu được biên soạn trên cơ sở tổng kết kinh nghiệm giảng dạy nhiều năm tại Khoa Tin học, Trường Đại học Sư phạm Huế, đồng thời kế thừa và mở rộng từ các nghiên cứu trong và ngoài nước về dạy học giải quyết vấn đề, tư duy tính toán và tích hợp AI trong giáo dục. Tác giả mong rằng tài liệu sẽ cung cấp được một nền tảng lý luận và thực hành vững chắc, giúp sinh viên bước vào nghề với sự tự tin và đủ năng lực để tổ chức những giờ học Tin học thực sự có giá trị — nơi học sinh được tư duy, được thử thách và được phát triển.
Do đây là lần biên soạn đầu tiên theo định hướng mở rộng này, tài liệu chắc chắn còn nhiều điểm cần bổ sung và hoàn thiện. Tác giả rất mong nhận được ý kiến đóng góp từ đồng nghiệp và sinh viên để tài liệu ngày càng hoàn chỉnh hơn.
Huế, 10 tháng 9 năm 2026
Nguyễn Thế Dũng Khoa Tin học — Trường Đại học Sư phạm Huế
CHƯƠNG 1: CƠ SỞ LÝ LUẬN VỀ TỔ CHỨC HOẠT ĐỘNG GIẢI QUYẾT VẤN ĐỀ TRONG DẠY HỌC TIN HỌC
Thời lượng: 4 tiết (2 tiết lý thuyết + 2 tiết thực hành)
________________________________________
A. MỤC TIÊU CHƯƠNG
Sau chương này, sinh viên có thể:
• Trình bày được khái niệm "vấn đề", "giải quyết vấn đề" và phân biệt với "bài tập thông thường".
• Phân loại được các mức độ vấn đề theo cấu trúc (well-structured/ill-structured) và theo độ mở.
• Giải thích được mối liên hệ giữa giải quyết vấn đề và tư duy tính toán (Computational Thinking).
• So sánh được ba mô hình giải quyết vấn đề: Polya, IDEAL, Design Thinking, và xác định mô hình phù hợp với từng dạng bài tập Tin học.
• Phân tích được một bài tập Tin học cụ thể theo 3 chiều: mức độ Bloom, mức độ giải quyết vấn đề, thành phần tư duy tính toán.
Chương này đóng vai trò nền tảng lý thuyết cho toàn bộ học phần — các chương sau (thiết kế tình huống có vấn đề, tổ chức hoạt động, hỗ trợ học sinh, đánh giá) đều xây dựng trên các khái niệm được thiết lập ở đây, với các ví dụ minh họa bằng chính nội dung Tin học phổ thông (không dùng ví dụ toán học chung chung).
________________________________________
B. NỘI DUNG LÝ THUYẾT (2 tiết)
1.1. Khái niệm vấn đề và giải quyết vấn đề
a) Khái niệm "vấn đề" (problem)
Trong tâm lý học nhận thức, một "vấn đề" xuất hiện khi chủ thể nhận thức có mục tiêu cần đạt được nhưng chưa có sẵn con đường (thủ tục, thuật giải) để đạt mục tiêu đó. Ba thành phần cấu trúc của một vấn đề:
Thành phần Mô tả Ví dụ trong Tin học
Trạng thái ban đầu (Given/Initial state) Dữ liệu, điều kiện đã biết Một dãy số chưa sắp xếp
Trạng thái đích (Goal state) Kết quả cần đạt Dãy số được sắp xếp tăng dần
Các thao tác/ràng buộc (Operators/Constraints) Các phép biến đổi được phép dùng Chỉ được dùng vòng lặp và phép so sánh, không dùng hàm sort() có sẵn
Điểm mấu chốt cần làm rõ cho sinh viên: một câu hỏi chỉ trở thành "vấn đề" khi người học chưa có sẵn thuật giải để giải quyết nó. Nếu học sinh đã được dạy sẵn thuật toán và chỉ áp dụng lại (ví dụ: đã học for loop và bài tập chỉ yêu cầu in ra 1-10), đó là bài tập luyện tập (exercise), không phải "vấn đề" theo nghĩa didactic. Đây là ranh giới quan trọng để phân biệt với các bài luyện cú pháp thuần túy.
b) Khái niệm "giải quyết vấn đề" (problem solving)
Là quá trình nhận thức có định hướng, trong đó chủ thể huy động kiến thức, kỹ năng, chiến lược tư duy để thu hẹp khoảng cách giữa trạng thái ban đầu và trạng thái đích, khi con đường đi chưa được biết trước (Newell & Simon, 1972; Mayer, 1992).
Trong dạy học Tin học, giải quyết vấn đề không chỉ là "ra được đáp số đúng" mà là quá trình học sinh:
1. Biểu diễn lại vấn đề (problem representation) — ví dụ: mô hình hóa bài toán quản lý điểm bằng cấu trúc dữ liệu nào.
2. Lập kế hoạch (thuật toán, lưu đồ, giả mã).
3. Thực thi (viết mã, chạy thử).
4. Kiểm tra và tinh chỉnh (debug, tối ưu).
→ Gợi ý sư phạm: khi đánh giá, GV cần đánh giá cả quá trình này, không chỉ sản phẩm cuối (điều này sẽ được khai triển kỹ ở Chương 4 — công cụ đánh giá).
________________________________________
1.2. Các mức độ của vấn đề
Dựa trên phân loại của Jonassen (2000) về "well-structured vs. ill-structured problems", có thể chia vấn đề trong dạy học Tin học thành 4 mức:
Mức Đặc điểm Ví dụ Tin học
Mức 1 – Bài toán đóng, có cấu trúc rõ (well-structured) Có duy nhất một đáp án đúng, một (hoặc ít) thuật toán chuẩn, dữ liệu đầy đủ Viết chương trình tính giai thừa của n
Mức 2 – Bài toán đóng nhưng có nhiều cách giải Đáp án duy nhất nhưng nhiều thuật toán/cách tiếp cận khác nhau, có sự đánh đổi về độ phức tạp Tìm phần tử lớn nhất trong mảng: duyệt tuyến tính hay chia để trị?
Mức 3 – Bài toán mở, có nhiều lời giải chấp nhận được Nhiều phương án đúng, cần lập luận để chọn phương án tối ưu theo tiêu chí Thiết kế cơ sở dữ liệu quản lý thư viện — nhiều mô hình schema đều "đúng"
Mức 4 – Vấn đề thực tiễn, cấu trúc kém (ill-structured) Mục tiêu không rõ ràng ngay từ đầu, thiếu dữ liệu, cần xác định lại vấn đề trong quá trình giải quyết "Xây dựng một ứng dụng hỗ trợ học sinh trường em ôn thi" — cần khảo sát nhu cầu, xác định phạm vi, ràng buộc kỹ thuật
Lưu ý sư phạm quan trọng: SGK phổ thông hiện hành chủ yếu dừng ở Mức 1–2. Mức 3–4 thường xuất hiện ở các bài tập lớn (dự án cuối kỳ) hoặc trong định hướng "Tin học ứng dụng"/"Khoa học máy tính" ở lớp 11-12 theo CT GDPT 2018. GV cần chủ động nâng cấp mức độ vấn đề của bài tập SGK bằng cách nới lỏng ràng buộc, bổ sung ngữ cảnh thực tế, hoặc yêu cầu học sinh tự đề xuất tiêu chí đánh giá lời giải.
________________________________________
1.3. Vai trò của giải quyết vấn đề trong môn Tin học
• Là bản chất đặc thù của môn Tin học: khác với các môn học khác, Tin học lấy giải quyết vấn đề bằng công cụ tin học làm mạch nội dung xuyên suốt (CT GDPT 2018 môn Tin học xác định "Giải quyết vấn đề với sự trợ giúp của máy tính" là một trong ba mạch nội dung cốt lõi, cùng với DL — Digital Literacy và CS — Computer Science).
• Là phương tiện để phát triển năng lực Tin học theo 5 thành phần: NLa (sử dụng, quản lý công cụ), NLb (ứng xử phù hợp chuẩn mực đạo đức, pháp luật), NLc (giải quyết vấn đề với sự hỗ trợ của công nghệ thông tin và truyền thông), NLd (ứng dụng công nghệ thông tin và truyền thông trong học và tự học), NLe (hợp tác trong môi trường số).
• Là cầu nối giữa kiến thức lập trình/thuật toán (thường trừu tượng) với năng lực vận dụng thực tiễn.
1.4. Tư duy tính toán (Computational Thinking) và giải quyết vấn đề
Theo Wing (2006) và mô hình được ISTE/CSTA cụ thể hóa, tư duy tính toán gồm 4 thành phần cốt lõi. Đây là công cụ phân tích sinh viên sẽ dùng xuyên suốt học phần (đặc biệt ở phần thực hành cuối chương), nên cần dạy kỹ với ví dụ song song:
Thành phần CT Định nghĩa Ví dụ minh họa: bài toán "Tìm số Fibonacci thứ n"
Phân rã (Decomposition) Chia vấn đề lớn thành các vấn đề con nhỏ hơn, dễ quản lý Tách thành: (1) xác định công thức truy hồi, (2) xây dựng vòng lặp/đệ quy, (3) xử lý trường hợp biên n=0, n=1
Nhận dạng mẫu (Pattern Recognition) Phát hiện điểm chung, quy luật lặp lại giữa các trường hợp Nhận ra F(n) = F(n-1) + F(n-2) là quy luật lặp cho mọi n ≥ 2
Trừu tượng hóa (Abstraction) Lược bỏ chi tiết không cần thiết, giữ lại đặc điểm bản chất Bỏ qua việc số Fibonacci dùng để làm gì trong thực tế, chỉ tập trung vào công thức toán và kiểu dữ liệu cần dùng
Thuật toán hóa (Algorithm Design) Xây dựng chuỗi bước có thứ tự, xác định để giải quyết Viết được thuật toán/mã giả cho việc tính F(n) bằng vòng lặp hoặc đệ quy
→ Mối quan hệ với giải quyết vấn đề: CT chính là bộ công cụ tư duy để thực hiện các bước của quá trình giải quyết vấn đề (mục 1.1b). Không có CT, học sinh khó có thể tự lập kế hoạch giải quyết một vấn đề mới.
1.5. Vai trò của bài tập trong dạy học Tin học
Bài tập không chỉ là công cụ luyện tập mà còn là phương tiện tổ chức nhận thức:
• Là "chất liệu" để tạo tình huống có vấn đề (sẽ học kỹ ở Chương 2).
• Là công cụ chẩn đoán năng lực (thông qua phân tích lỗi, chiến lược giải của học sinh).
• Là phương tiện phân hóa dạy học (một bài tập có thể được biến thể theo nhiều mức độ khó khác nhau cho các đối tượng học sinh khác nhau — kỹ thuật "scaffolding theo bài tập" sẽ được học ở Chương 3).
Phân biệt 3 loại bài tập thường gặp trong SGK Tin học, theo chức năng sư phạm:
Loại bài tập Chức năng Mức độ "vấn đề"
Bài tập luyện cú pháp (drill) Củng cố kỹ năng viết mã đúng cú pháp Không phải vấn đề (đã có thuật giải)
Bài tập vận dụng thuật toán đã học Áp dụng thuật toán vào tình huống mới Vấn đề mức 1-2
Bài tập/dự án mở Yêu cầu tự thiết kế giải pháp Vấn đề mức 3-4
________________________________________
1.6. Các mô hình giải quyết vấn đề
Đây là nội dung trọng tâm của chương — sinh viên cần nắm vững đủ sâu để có thể áp dụng làm khung tổ chức hoạt động ở Chương 3.
a) Mô hình Polya (1945) — "How to Solve It"
Gồm 4 bước, vốn được xây dựng cho toán học nhưng chuyển hóa tốt sang Tin học:
Bước Polya Diễn giải trong Tin học
1. Hiểu vấn đề (Understand the problem) Xác định input/output, ràng buộc, ví dụ minh họa
2. Lập kế hoạch (Devise a plan) Chọn cấu trúc dữ liệu, thuật toán, viết giả mã/lưu đồ
3. Thực hiện kế hoạch (Carry out the plan) Viết mã nguồn theo kế hoạch
4. Nhìn lại (Look back) Kiểm thử với các test case, đánh giá độ phức tạp, tối ưu hóa, đối chiếu lại với yêu cầu ban đầu
Ưu điểm: đơn giản, dễ dạy cho sinh viên/học sinh mới bắt đầu; phù hợp với bài toán mức 1-2. Hạn chế: bước "nhìn lại" trong thực tế lập trình thường bị bỏ qua nếu GV không nhấn mạnh; không phản ánh tính lặp đi lặp lại (iterative) của quá trình lập trình thực tế (viết – chạy – lỗi – sửa).
b) Mô hình IDEAL (Bransford & Stein, 1984)
I – Identify the problem (Nhận diện vấn đề) D – Define and represent the problem (Xác định và biểu diễn vấn đề) E – Explore possible strategies (Khám phá các chiến lược khả thi) A – Act on the strategy (Thực hiện chiến lược) L – Look back and evaluate (Nhìn lại và đánh giá)
So với Polya: IDEAL bổ sung rõ bước "Explore" — khám phá nhiều chiến lược trước khi chọn, phù hợp với bài toán mức 2-3 (có nhiều cách giải). Đây là điểm GV Tin học nên khai thác khi dạy các bài có đánh đổi thuật toán (ví dụ: sắp xếp — chọn giữa Bubble Sort, Quick Sort, Merge Sort tùy ràng buộc về bộ nhớ/thời gian).
c) Mô hình Design Thinking (Stanford d.school)
5 giai đoạn: Empathize → Define → Ideate → Prototype → Test (thường lặp lại vòng, không tuyến tính).
Giai đoạn Trong dạy học Tin học
Empathize Tìm hiểu người dùng cuối/ngữ cảnh thực tế (ai sẽ dùng phần mềm này? họ gặp khó khăn gì?)
Define Phát biểu lại vấn đề dưới dạng "How might we...?"
Ideate Brainstorm nhiều giải pháp/kiến trúc hệ thống khác nhau
Prototype Xây dựng bản mẫu/MVP (ví dụ: giao diện demo, sơ đồ CSDL sơ bộ)
Test Thử nghiệm, thu thập phản hồi, quay lại các bước trước để cải tiến
Phù hợp nhất với vấn đề mức 4 (dự án phần mềm thực tế, bài toán ill-structured), khi mục tiêu ban đầu chưa rõ ràng và cần được làm rõ dần qua tương tác với người dùng/thực tế.
Bảng so sánh tổng hợp — công cụ cho sinh viên chọn mô hình phù hợp:
Tiêu chí Polya IDEAL Design Thinking
Mức độ vấn đề phù hợp 1–2 2–3 3–4
Tính tuyến tính Cao Trung bình Thấp (lặp vòng)
Nhấn mạnh Kế hoạch – thực hiện Khám phá nhiều chiến lược Con người – ngữ cảnh thực tế
Ví dụ áp dụng Bài tập thuật toán trong SGK Bài toán tối ưu thuật toán Dự án phần mềm cuối kỳ
1.7. Mối quan hệ giữa bài tập Tin học và năng lực giải quyết vấn đề
Sơ đồ logic cần truyền đạt cho sinh viên:
Bài tập (với mức độ vấn đề phù hợp) → được tổ chức theo một mô hình giải quyết vấn đề (Polya/IDEAL/DT) → huy động các thành phần tư duy tính toán → hình thành và phát triển năng lực giải quyết vấn đề với sự hỗ trợ của máy tính (NLc trong CT GDPT 2018).
Đây chính là logic mà toàn bộ học phần sẽ triển khai: Chương 1 (lý luận) → Chương 2 (thiết kế tình huống/bài tập) → Chương 3 (tổ chức, hỗ trợ) → Chương 4 (đánh giá) → Chương 5 (tích hợp AI).
________________________________________
C. HOẠT ĐỘNG THỰC HÀNH (2 tiết)
Mục tiêu thực hành
Sinh viên phân tích được bài tập Tin học SGK theo 3 chiều: Bloom, mức độ giải quyết vấn đề, thành phần tư duy tính toán.
Chuẩn bị
GV chọn sẵn 4-6 bài tập trích từ SGK Tin học hiện hành (lớp 8, 10, 11) thuộc các mạch nội dung khác nhau (lập trình, cơ sở dữ liệu, mạng máy tính) để đảm bảo tính đa dạng.
Công cụ phân tích — Phiếu làm việc nhóm (mẫu)
Bài tập Mức độ Bloom (Nhớ/Hiểu/Vận dụng/Phân tích/Đánh giá/Sáng tạo) Mức độ vấn đề (1-4, theo mục 1.2) Thành phần CT nổi bật (Phân rã/Nhận dạng mẫu/Trừu tượng hóa/Thuật toán hóa) Mô hình GQVĐ phù hợp nhất Đề xuất cải biến để nâng mức độ vấn đề
VD: "Viết chương trình kiểm tra số nguyên tố" Vận dụng Mức 1-2 Thuật toán hóa, Nhận dạng mẫu Polya Yêu cầu tối ưu độ phức tạp (giới hạn thời gian chạy), hoặc mở rộng: tìm tất cả số nguyên tố trong đoạn [a,b] với a,b lớn
Tiến trình tổ chức (gợi ý 2 tiết = 90 phút)
1. Giới thiệu nhiệm vụ (10 phút): GV phát phiếu, giải thích công cụ phân tích, làm mẫu 1 bài tập chung với cả lớp.
2. Làm việc nhóm (40 phút): Chia nhóm 3-4 sinh viên, mỗi nhóm phân tích 2-3 bài tập được giao (khác nhau giữa các nhóm).
3. Báo cáo và phản biện chéo (25 phút): Mỗi nhóm trình bày 1 bài tập tiêu biểu; các nhóm khác phản biện, đặc biệt tranh luận về mức độ Bloom/mức độ vấn đề (thường có bất đồng — đây là điểm tốt để thảo luận sâu).
4. Tổng kết (15 phút): GV chốt lại các tiêu chí phân biệt mức độ, nhấn mạnh: việc phân loại bài tập là bước tiền đề bắt buộc trước khi thiết kế hoạt động giải quyết vấn đề (chuẩn bị cho Chương 2).
Câu hỏi thảo luận mở rộng (dùng để kết thúc buổi học hoặc giao về nhà)
1. Một bài tập có thể "nhảy mức" từ Mức 1 lên Mức 3 chỉ bằng cách thay đổi cách đặt câu hỏi hay không? Cho ví dụ cụ thể với một bài tập SGK.
2. Vì sao mô hình Design Thinking ít được áp dụng cho các bài tập lập trình cơ bản (Mức 1-2) nhưng lại rất phù hợp với dự án cuối kỳ?
3. Theo Thầy/Cô, thành phần tư duy tính toán nào (trong 4 thành phần) thường bị bỏ sót nhất khi GV phổ thông ra bài tập theo kiểu truyền thống? Vì sao?
________________________________________
D. TÀI LIỆU THAM KHẢO CHO CHƯƠNG
• Bộ GD&ĐT (2018). Chương trình giáo dục phổ thông môn Tin học (Thông tư 32/2018/TT-BGDĐT).
• Polya, G. (1945). How to Solve It. Princeton University Press.
• Bransford, J. D., & Stein, B. S. (1984). The IDEAL Problem Solver. Freeman.
• Jonassen, D. H. (2000). Toward a design theory of problem solving. Educational Technology Research and Development, 48(4), 63–85.
• Wing, J. M. (2006). Computational thinking. Communications of the ACM, 49(3), 33–35.
• CSTA & ISTE (2011). Computational Thinking Teacher Resources.
• Stanford d.school. An Introduction to Design Thinking Process Guide.
CHƯƠNG 2: PHÂN TÍCH BÀI TẬP TIN HỌC DƯỚI GÓC NHÌN PHÁT TRIỂN NĂNG LỰC
Thời lượng: 6 tiết (3 tiết lý thuyết + 3 tiết thực hành)
________________________________________
A. MỤC TIÊU CHƯƠNG
Chương 1 đã trang bị cho sinh viên khung lý luận (khái niệm vấn đề, mức độ vấn đề, tư duy tính toán, các mô hình giải quyết vấn đề). Chương 2 chuyển từ lý luận chung sang kỹ năng nghề nghiệp cốt lõi: phân tích một bài tập Tin học cụ thể để làm cơ sở thiết kế hoạt động dạy học (sẽ triển khai ở Chương 3). Đây là chương có tính "bản lề" — nếu sinh viên phân tích bài tập không chính xác, các bước thiết kế tình huống, tổ chức hoạt động, đánh giá ở các chương sau sẽ thiếu căn cứ.
Sau chương này, sinh viên có thể:
• Phân loại được bài tập Tin học theo 8 nhóm nội dung (khái niệm, thuật toán, lập trình, dữ liệu, CSDL, AI, mạng máy tính, Web).
• Phân tích một bài tập theo 7 chiều: kiến thức, kỹ năng, năng lực, tư duy tính toán, mức độ Bloom, lỗi sai thường gặp, khả năng sử dụng AI.
• Thiết kế và sử dụng prompt AI để hỗ trợ phân tích bài tập một cách hiệu quả, có kiểm soát.
• Lập được phiếu phân tích bài tập hoàn chỉnh, áp dụng cho tối thiểu 10 bài tập SGK thuộc nhiều mạch nội dung khác nhau.
________________________________________
B. NỘI DUNG LÝ THUYẾT (3 tiết)
2.1. Phân loại bài tập Tin học
Việc phân loại theo nội dung (khác với phân loại theo mức độ vấn đề đã học ở Chương 1, mục 1.2) giúp giáo viên nhận diện đặc thù về tư duy và kỹ năng mà từng nhóm bài tập đòi hỏi, từ đó lựa chọn chiến lược tổ chức phù hợp (sẽ học ở Chương 3). Hai hệ trục phân loại này độc lập nhưng bổ sung cho nhau: một bài tập lập trình có thể ở Mức độ vấn đề 1 hoặc Mức độ vấn đề 4, tùy cách GV đặt yêu cầu.
Dưới đây là 8 nhóm bài tập, gắn với mạch nội dung của CT GDPT 2018 môn Tin học (DL – Digital Literacy, CS – Computer Science, ICT – Information and Communication Technology):
a) Bài tập khái niệm (Conceptual exercises)
Yêu cầu học sinh giải thích, phân biệt, hệ thống hóa các khái niệm lý thuyết, không đòi hỏi viết mã hay thao tác thực hành.
Đặc điểm nhận diện: động từ chỉ hành động thường là "trình bày", "phân biệt", "so sánh", "giải thích vì sao". Ví dụ: "Phân biệt biến và hằng trong lập trình. Vì sao một chương trình cần cả hai loại này?" Tư duy chủ đạo: trừu tượng hóa (abstraction) — đòi hỏi nắm bản chất, không phải kỹ năng thao tác. Nguy cơ sư phạm thường gặp: GV dễ biến bài tập khái niệm thành bài tập ghi nhớ thuần túy (Mức Bloom "Nhớ") thay vì yêu cầu học sinh vận dụng khái niệm để lý giải một tình huống cụ thể.
b) Bài tập thuật toán (Algorithmic exercises)
Yêu cầu xây dựng hoặc phân tích quy trình các bước giải quyết vấn đề, có thể biểu diễn bằng ngôn ngữ tự nhiên, sơ đồ khối, hoặc mã giả — chưa cần cài đặt bằng ngôn ngữ lập trình cụ thể.
Ví dụ: "Mô tả thuật toán tìm giá trị lớn nhất trong một dãy số bằng sơ đồ khối." Tư duy chủ đạo: thuật toán hóa, phân rã. Lưu ý phân biệt với bài tập lập trình: nhiều GV nhầm lẫn hai loại này. Bài tập thuật toán đánh giá tư duy logic và trình tự các bước; bài tập lập trình còn đánh giá thêm kỹ năng cú pháp và công cụ. Một học sinh có thể làm tốt bài tập thuật toán nhưng gặp khó khăn khi chuyển sang cài đặt (và ngược lại) — đây là thông tin chẩn đoán quan trọng (sẽ dùng ở mục 2.2, "lỗi sai thường gặp").
c) Bài tập lập trình (Programming exercises)
Yêu cầu cài đặt (coding) một giải pháp bằng ngôn ngữ lập trình cụ thể (Python, Pascal, Scratch tùy cấp học), chạy được và cho kết quả đúng.
Ví dụ: "Viết chương trình Python nhập vào danh sách điểm số và in ra điểm trung bình." Tư duy chủ đạo: cả 4 thành phần CT, nhưng nổi bật là thuật toán hóa và nhận dạng mẫu (tái sử dụng cấu trúc lập trình đã học). Đặc thù cần lưu ý khi phân tích: bài tập lập trình luôn có hai lớp lỗi cần phân biệt — lỗi cú pháp (syntax error, dễ sửa, không phản ánh tư duy) và lỗi logic/thuật toán (semantic error, phản ánh trực tiếp năng lực giải quyết vấn đề). Việc phân tích bài tập cần dự đoán trước cả hai loại lỗi này (chi tiết ở mục 2.2).
d) Bài tập dữ liệu (Data-handling exercises)
Yêu cầu xử lý, biểu diễn, trực quan hóa hoặc phân tích dữ liệu — không nhất thiết gắn với lập trình (có thể dùng bảng tính) hoặc gắn với lập trình (xử lý file, mảng, danh sách).
Ví dụ: "Cho bảng dữ liệu điểm thi của lớp dưới dạng file CSV, hãy tính điểm trung bình từng môn và vẽ biểu đồ so sánh." Tư duy chủ đạo: trừu tượng hóa (chọn biểu diễn dữ liệu phù hợp), nhận dạng mẫu (phát hiện xu hướng trong dữ liệu). Điểm khác biệt với bài tập lập trình thuần túy: trọng tâm đánh giá là khả năng đọc hiểu và diễn giải dữ liệu, không chỉ là kết quả tính toán đúng.
e) Bài tập cơ sở dữ liệu (Database exercises)
Yêu cầu thiết kế schema, viết truy vấn (query), hoặc chuẩn hóa dữ liệu.
Ví dụ: "Thiết kế cơ sở dữ liệu quản lý mượn-trả sách cho thư viện trường học, gồm tối thiểu 3 bảng có quan hệ với nhau." Tư duy chủ đạo: trừu tượng hóa (mô hình hóa thực thể - quan hệ), phân rã (tách các bảng theo chức năng). Đặc thù: đây thường là bài tập mức độ vấn đề cao (Mức 3 theo Chương 1) vì thường có nhiều schema đều hợp lệ, đòi hỏi học sinh lập luận, biện minh cho lựa chọn thiết kế của mình — phù hợp áp dụng mô hình IDEAL (khám phá nhiều chiến lược trước khi chọn).
f) Bài tập AI (AI-related exercises)
Nội dung mới trong CT GDPT 2018 (định hướng Khoa học máy tính, lớp 11-12), yêu cầu học sinh tìm hiểu, thử nghiệm, hoặc đánh giá ứng dụng của AI.
Ví dụ: "Sử dụng một công cụ AI tạo sinh để soạn một đoạn văn, sau đó chỉ ra 3 điểm cần kiểm chứng lại thông tin do AI cung cấp." Tư duy chủ đạo: trừu tượng hóa (hiểu nguyên lý hoạt động ở mức khái quát), tư duy phản biện (không thuộc 4 thành phần CT cổ điển nhưng ngày càng được nhấn mạnh trong dạy học AI phổ thông). Lưu ý sư phạm đặc biệt: bài tập AI cần tích hợp giáo dục về sử dụng có trách nhiệm (đạo đức, bản quyền, thiên kiến dữ liệu) — đây là thành phần năng lực NLb (theo khung 5 thành phần đã nêu ở Chương 1).
g) Bài tập mạng máy tính (Networking exercises)
Yêu cầu hiểu nguyên lý hoạt động, cấu hình, hoặc khắc phục sự cố liên quan đến mạng máy tính và Internet.
Ví dụ: "Giải thích quá trình một trình duyệt gửi yêu cầu và nhận phản hồi từ máy chủ web. Vẽ sơ đồ minh họa." Tư duy chủ đạo: trừu tượng hóa (mô hình hóa hệ thống phân tầng), phân rã (tách các giao thức/tầng chức năng). Đặc thù: thường thiên về bài tập khái niệm (mục a) nhưng có thể nâng cấp thành bài tập thực hành cấu hình mạng (mô phỏng) để tăng mức độ vấn đề.
h) Bài tập Web (Web development exercises)
Yêu cầu thiết kế, xây dựng trang web hoặc thành phần web (HTML/CSS/JS cơ bản, tùy chương trình).
Ví dụ: "Xây dựng một trang web đơn giản giới thiệu lớp học, có menu điều hướng và ít nhất 2 trang liên kết với nhau." Tư duy chủ đạo: thuật toán hóa (logic tương tác nếu có JS), trừu tượng hóa (cấu trúc thông tin, bố cục). Đặc thù: là dạng bài tập có tính sản phẩm cao (product-oriented), dễ chuyển hóa thành dự án mức độ vấn đề 3-4, phù hợp áp dụng Design Thinking.
Bảng tổng hợp 8 nhóm bài tập (dùng làm công cụ tra cứu nhanh):
Nhóm Trọng tâm đánh giá Thành phần CT nổi bật Mô hình GQVĐ thường phù hợp (Ch.1)
Khái niệm Hiểu bản chất Trừu tượng hóa Polya
Thuật toán Tư duy logic, trình tự Thuật toán hóa, phân rã Polya, IDEAL
Lập trình Cú pháp + logic Cả 4 thành phần Polya, IDEAL
Dữ liệu Đọc hiểu, diễn giải Trừu tượng hóa, nhận dạng mẫu IDEAL
Cơ sở dữ liệu Mô hình hóa, lập luận thiết kế Trừu tượng hóa, phân rã IDEAL
AI Hiểu nguyên lý + phản biện Trừu tượng hóa Design Thinking
Mạng máy tính Mô hình hóa hệ thống Trừu tượng hóa, phân rã Polya
Web Thiết kế sản phẩm Thuật toán hóa, trừu tượng hóa Design Thinking
Lưu ý quan trọng cho sinh viên: trong thực tế, một bài tập có thể thuộc nhiều nhóm cùng lúc (ví dụ: một dự án "xây dựng website quản lý điểm học sinh" vừa là bài tập Web, vừa là bài tập CSDL, vừa là bài tập lập trình). Việc phân loại không nhằm "đóng khung cứng" mà nhằm xác định trọng tâm năng lực cần đánh giá.
________________________________________
2.2. Phân tích mục tiêu bài tập
Đây là kỹ năng trung tâm của chương. Sinh viên cần học cách "giải phẫu" một bài tập theo 7 chiều phân tích. Cần nhấn mạnh: 7 chiều này không độc lập mà có quan hệ logic chặt chẽ — kiến thức/kỹ năng là nền tảng, năng lực và tư duy tính toán là kết quả tích hợp, mức độ Bloom là "thước đo" độ sâu nhận thức, còn lỗi sai và khả năng dùng AI là thông tin phục vụ trực tiếp cho việc tổ chức hỗ trợ (Chương 3) và thiết kế đánh giá (Chương 4).
a) Xác định kiến thức (Knowledge)
Là những đơn vị kiến thức cụ thể (khái niệm, định nghĩa, quy tắc, cú pháp) mà học sinh cần huy động để giải bài tập.
Câu hỏi định hướng phân tích: "Học sinh cần biết điều gì trước khi bắt tay vào giải bài tập này?" Ví dụ (bài tập: viết chương trình kiểm tra năm nhuận): kiến thức cần có gồm cú pháp câu lệnh điều kiện (if-elif-else), toán tử chia lấy dư (%), và quy tắc xác định năm nhuận (kiến thức liên môn — Toán/thực tế, không phải kiến thức lập trình thuần túy). Lưu ý: GV cần phân biệt kiến thức tiên quyết (đã học từ trước, là điều kiện để giải bài) và kiến thức mới (bài tập này nhằm củng cố/hình thành). Nhầm lẫn hai loại này dẫn đến đặt bài tập sai thời điểm trong tiến trình dạy học.
b) Xác định kỹ năng (Skill)
Là khả năng thao tác, vận dụng cụ thể mà bài tập rèn luyện — khác với kiến thức (biết) ở chỗ kỹ năng là "làm được".
Ví dụ (cùng bài tập trên): kỹ năng viết đúng cú pháp điều kiện lồng nhau, kỹ năng kiểm thử chương trình với nhiều bộ dữ liệu (test case) khác nhau (ví dụ: năm 2000, 1900, 2024, 2023 — để bao quát các trường hợp đặc biệt của quy tắc năm nhuận). Điểm cần nhấn mạnh với sinh viên: việc liệt kê kỹ năng cần đủ cụ thể để có thể quan sát và đánh giá được (không viết chung chung "kỹ năng lập trình" mà cần "kỹ năng viết điều kiện lồng nhau đúng thứ tự ưu tiên").
c) Xác định năng lực (Competency)
Đối chiếu với khung 5 thành phần năng lực Tin học (NLa–NLe) đã giới thiệu ở Chương 1, mục 1.3.
Ví dụ (bài tập năm nhuận): chủ yếu phát triển NLc (giải quyết vấn đề với sự hỗ trợ của công nghệ thông tin). Nếu bài tập được mở rộng thành "viết chương trình tra cứu và hiển thị số ngày trong tháng bất kỳ của năm bất kỳ, có giao diện nhập liệu thân thiện", sẽ bổ sung thêm NLa (sử dụng công cụ) và một phần NLd. Lưu ý phương pháp luận: năng lực không quan sát trực tiếp được — chỉ suy ra được thông qua biểu hiện hành vi khi học sinh thực hiện kiến thức và kỹ năng nêu trên trong một tình huống cụ thể. Đây là lý do vì sao bước phân tích kiến thức/kỹ năng (mục a, b) phải đi trước bước xác định năng lực.
d) Xác định tư duy tính toán (Computational Thinking)
Áp dụng lại 4 thành phần đã học ở Chương 1 (mục 1.4): phân rã, nhận dạng mẫu, trừu tượng hóa, thuật toán hóa — nhưng lần này phân tích cụ thể cho từng bài tập thay vì ở mức khái quát.
Ví dụ (bài tập năm nhuận):
• Phân rã: tách điều kiện năm nhuận thành các trường hợp con (chia hết cho 4, ngoại lệ chia hết cho 100, ngoại lệ của ngoại lệ chia hết cho 400).
• Nhận dạng mẫu: nhận ra cấu trúc "điều kiện lồng nhau có ngoại lệ" tương tự các bài toán phân loại khác.
• Trừu tượng hóa: bỏ qua ý nghĩa lịch/thiên văn của năm nhuận, chỉ giữ lại quy tắc toán học.
• Thuật toán hóa: sắp xếp thứ tự kiểm tra điều kiện sao cho đúng logic (kiểm tra chia hết cho 400 trước hay sau chia hết cho 100 đều được, miễn logic đúng).
e) Xác định mức độ Bloom (Thang Bloom cải tiến – Anderson & Krathwohl, 2001)
Mức Động từ điển hình Áp dụng cho bài tập năm nhuận (biến thể)
Nhớ liệt kê, nêu Nêu quy tắc xác định năm nhuận
Hiểu giải thích, tóm tắt Giải thích vì sao năm 1900 không nhuận nhưng 2000 nhuận
Vận dụng áp dụng, tính toán Viết chương trình kiểm tra một năm bất kỳ
Phân tích so sánh, phân loại Phân loại một danh sách 100 năm thành nhuận/không nhuận và thống kê tỉ lệ
Đánh giá phản biện, nhận xét Đánh giá một đoạn mã có sẵn có kiểm tra năm nhuận đúng chưa, chỉ ra lỗi (nếu có)
Sáng tạo thiết kế, đề xuất Thiết kế một ứng dụng lịch vạn niên có tính năng đánh dấu năm nhuận
Lưu ý sư phạm: cùng một "chủ đề nội dung" (năm nhuận) có thể được viết lại thành bài tập ở bất kỳ mức Bloom nào — đây là kỹ thuật quan trọng sinh viên cần thực hành: biến đổi (transform) một bài tập từ mức thấp lên mức cao bằng cách thay đổi động từ yêu cầu và bối cảnh, mà không cần thay đổi kiến thức nền.
f) Dự đoán lỗi sai thường gặp (Common misconceptions/errors)
Đây là chiều phân tích có tính chẩn đoán, chuẩn bị trực tiếp cho việc thiết kế hỗ trợ (scaffolding).
Phân loại lỗi theo 3 nhóm:
Nhóm lỗi Bản chất Ví dụ (bài tập năm nhuận)
Lỗi cú pháp (syntax) Sai quy tắc ngôn ngữ lập trình Quên dấu : sau if, sai thụt lề (indentation) trong Python
Lỗi khái niệm (conceptual/misconception) Hiểu sai bản chất vấn đề Học sinh nghĩ "chia hết cho 4 là nhuận" mà quên ngoại lệ chia hết cho 100
Lỗi logic/thuật toán (logic) Sai trình tự hoặc điều kiện xử lý Đặt sai thứ tự ưu tiên các điều kiện if-elif, dẫn đến năm 2000 bị đánh giá sai
Vai trò sư phạm: việc dự đoán trước lỗi sai giúp GV: (1) chuẩn bị câu hỏi gợi mở đúng lúc thay vì đưa đáp án ngay (kỹ thuật sẽ học ở Chương 3 — questioning, debugging hỗ trợ), (2) thiết kế bộ test case "bẫy" các lỗi phổ biến khi kiểm tra bài làm học sinh, (3) xây dựng rubric đánh giá có tính đến các lỗi điển hình (Chương 4).
g) Xác định khả năng sử dụng AI (AI-affordance)
Chiều phân tích mới, đặc thù của học phần này. Với mỗi bài tập, cần xác định: AI có thể hỗ trợ ở khâu nào của quá trình giải quyết vấn đề, và ở mức độ nào là phù hợp (không lạm dụng, không để AI "làm hộ" toàn bộ tư duy).
Khung phân tích gợi ý — đối chiếu với 4 bước giải quyết vấn đề (Polya, Chương 1):
Bước giải quyết vấn đề AI có thể hỗ trợ như thế nào Rủi ro nếu lạm dụng
Hiểu vấn đề Giải thích lại đề bài bằng ngôn ngữ đơn giản hơn, cho ví dụ minh họa Học sinh không tự đọc hiểu đề
Lập kế hoạch Gợi ý các hướng tiếp cận khác nhau, so sánh ưu-nhược điểm Học sinh nhận thuật toán có sẵn mà không tự tư duy
Thực hiện Giải thích lỗi cú pháp, gợi ý sửa (không viết hộ toàn bộ mã) Học sinh sao chép mã AI sinh ra mà không hiểu
Nhìn lại Đề xuất thêm test case, gợi ý hướng tối ưu Học sinh không tự đánh giá được chất lượng lời giải của mình
→ Kết luận phân tích cho mỗi bài tập nên ở dạng: "Bài tập này nên cho phép học sinh dùng AI ở bước X với vai trò Y, và không nên dùng AI ở bước Z vì sẽ làm mất mục tiêu năng lực cốt lõi (kiến thức/kỹ năng đã xác định ở mục a, b)."
________________________________________
2.3. Tích hợp AI vào quy trình phân tích bài tập của giáo viên
Phần này khác với mục 2.2g ở trên: mục 2.2g phân tích AI từ góc nhìn học sinh (AI hỗ trợ học sinh giải bài tập như thế nào); còn phần này hướng dẫn sinh viên (với tư cách giáo viên tương lai) sử dụng AI như một trợ lý trong chính công việc phân tích bài tập.
5 tác vụ AI có thể hỗ trợ giáo viên, với ví dụ prompt cụ thể:
a) Phân tích đề bài
Prompt mẫu: "Đây là một bài tập Tin học lớp [X]: [dán đề bài].
Hãy phân tích: (1) input/output của bài toán, (2) các ràng buộc
ẩn chưa được nêu rõ trong đề, (3) các trường hợp biên (edge case)
cần lưu ý."
b) Xác định mục tiêu học tập
Prompt mẫu: "Với bài tập trên, hãy đề xuất mục tiêu học tập theo
3 thành phần: kiến thức, kỹ năng, năng lực (đối chiếu khung năng
lực Tin học CT GDPT 2018: NLa-NLe)."
c) Phân loại bài tập
Prompt mẫu: "Xác định bài tập này thuộc nhóm nào trong 8 nhóm:
khái niệm/thuật toán/lập trình/dữ liệu/CSDL/AI/mạng máy tính/Web,
và ước lượng mức độ vấn đề theo thang 1-4 (well-structured đến
ill-structured)."
d) Dự đoán lỗi sai
Prompt mẫu: "Với vai trò một giáo viên có kinh nghiệm, hãy liệt
kê 5 lỗi phổ biến nhất mà học sinh lớp [X] thường gặp khi làm
bài tập này, phân loại theo lỗi cú pháp/khái niệm/logic."
e) Đề xuất nhiều cách giải và các mức độ hỗ trợ
Prompt mẫu: "Đề xuất 3 cách giải bài tập này với độ phức tạp
tăng dần, và với mỗi cách giải, đề xuất 3 mức độ gợi ý (hint)
theo nguyên tắc từ gợi ý ít nhất đến nhiều nhất, không đưa đáp
án trực tiếp ở mức gợi ý đầu tiên."
Nguyên tắc sử dụng AI có kiểm soát (rất quan trọng — cần nhấn mạnh với sinh viên):
1. AI là trợ lý phân tích, không phải người quyết định cuối cùng. Mọi kết quả AI đề xuất cần được GV đối chiếu, kiểm chứng lại với thực tế trình độ học sinh của lớp mình — điều mà AI không thể biết chính xác.
2. Kiểm tra tính chính xác kỹ thuật. AI có thể mắc lỗi khi phân tích thuật toán phức tạp hoặc CSDL — GV cần tự chạy thử/kiểm tra lại các đề xuất mã nguồn hoặc thuật toán.
3. Không để AI thay thế hoàn toàn tư duy sư phạm của GV. Việc AI đề xuất mục tiêu Bloom hay năng lực chỉ là gợi ý ban đầu; quyết định cuối cùng phụ thuộc vào bối cảnh dạy học cụ thể (đối tượng học sinh, thời lượng, mục tiêu chương trình).
4. Ghi chép lại quy trình sử dụng AI như một phần hồ sơ chuyên môn, hữu ích khi trao đổi chuyên môn hoặc kiểm tra đánh giá công tác giảng dạy.
Mối liên hệ với các chương sau: kỹ năng dùng AI để phân tích bài tập ở đây là nền tảng cho việc dùng AI ở quy mô lớn hơn — thiết kế tình huống có vấn đề (Chương 3) và xây dựng công cụ đánh giá (Chương 4), sẽ được khai triển kỹ ở Chương 5 (tích hợp AI toàn diện).
________________________________________
C. HOẠT ĐỘNG THỰC HÀNH (3 tiết)
Mục tiêu thực hành
Sinh viên áp dụng đầy đủ khung phân tích (8 nhóm phân loại + 7 chiều mục tiêu) cho tối thiểu 10 bài tập SGK Tin học, có sử dụng AI hỗ trợ một cách có kiểm soát.
Chuẩn bị
• GV cung cấp (hoặc yêu cầu sinh viên tự sưu tầm) 10-15 bài tập trích từ SGK Tin học các khối lớp (8, 10, 11), đảm bảo phủ ít nhất 5 trong 8 nhóm phân loại ở mục 2.1.
• Sinh viên mang máy tính/thiết bị có kết nối Internet để sử dụng công cụ AI trong buổi thực hành.
Phiếu phân tích bài tập (mẫu chuẩn — sinh viên dùng để nộp sản phẩm)
Tiêu chí Nội dung phân tích
1. Đề bài (ghi nguyên văn hoặc trích dẫn SGK, trang, bài số)
2. Nhóm bài tập (2.1) Chọn 1-2 trong 8 nhóm
3. Kiến thức cần có Liệt kê cụ thể
4. Kỹ năng cần rèn Liệt kê cụ thể, có thể quan sát được
5. Năng lực phát triển Đối chiếu NLa–NLe
6. Thành phần tư duy tính toán Phân tích cả 4 thành phần, chỉ rõ biểu hiện cụ thể trong bài
7. Mức độ Bloom Xác định mức, giải thích căn cứ
8. Mức độ vấn đề (theo Ch.1) 1-4, giải thích căn cứ
9. Lỗi sai dự đoán Tối thiểu 3 lỗi, phân loại cú pháp/khái niệm/logic
10. Khả năng dùng AI Bước nào nên hỗ trợ, bước nào không nên (theo khung 2.2g)
11. Prompt AI đã sử dụng (nếu có) Ghi lại prompt và đánh giá ngắn gọn về độ tin cậy của kết quả AI trả về
Tiến trình tổ chức (gợi ý 3 tiết = 135 phút)
1. Ôn tập và làm mẫu (20 phút): GV cùng cả lớp phân tích mẫu 1 bài tập đầy đủ theo phiếu, có minh họa sử dụng AI trực tiếp (dùng 1-2 prompt ở mục 2.3) để sinh viên thấy quy trình thực tế.
2. Làm việc cá nhân/nhóm đôi (75 phút): Mỗi sinh viên (hoặc nhóm 2 người) chọn/được giao 3-5 bài tập, hoàn thành phiếu phân tích đầy đủ, có sử dụng AI hỗ trợ cho ít nhất 2 trong 5 tác vụ ở mục 2.3.
3. Trao đổi chéo và phản biện (25 phút): Các nhóm đổi phiếu phân tích cho nhau, đánh giá chéo dựa trên tiêu chí: tính chính xác, tính cụ thể (không chung chung), sự phù hợp giữa các chiều phân tích với nhau.
4. Tổng kết (15 phút): GV chốt các lỗi thường gặp khi sinh viên phân tích bài tập (ví dụ: liệt kê năng lực nhưng không có căn cứ từ kiến thức/kỹ năng; nhầm lẫn mức độ Bloom với mức độ vấn đề; lạm dụng AI mà không kiểm chứng), kết nối sang Chương 3: "Từ kết quả phân tích này, chúng ta sẽ dùng làm căn cứ để thiết kế tình huống có vấn đề — bài tập tiếp theo."
Sản phẩm cần nộp
Tập hợp 10 phiếu phân tích bài tập hoàn chỉnh (có thể làm theo nhóm nhưng đảm bảo đa dạng ít nhất 5/8 nhóm bài tập và đủ 3 khối lớp), nộp dưới dạng file word/excel, dùng làm ngân hàng dữ liệu cho các bài thực hành ở Chương 3 và Chương 4 (khuyến khích GV thiết kế các chương sau liên thông trực tiếp với sản phẩm này, tạo tính xuyên suốt cho học phần).
Câu hỏi thảo luận mở rộng
1. Có bài tập nào trong 10 bài tập đã phân tích mà việc dùng AI hỗ trợ học sinh giải lại làm giảm giá trị sư phạm của bài tập đó không? Vì sao?
2. Giữa việc GV tự phân tích bài tập và dùng AI hỗ trợ phân tích, đâu là điểm khác biệt quan trọng nhất về chất lượng/độ tin cậy? Cho ví dụ cụ thể từ bài tập bạn đã phân tích.
3. Bài tập nào trong số đã phân tích có thể dễ dàng "nâng mức" từ well-structured lên ill-structured (theo mục 1.2) chỉ bằng cách thay đổi cách đặt vấn đề? Hãy viết lại đề bài minh họa.
________________________________________
D. TÀI LIỆU THAM KHẢO CHO CHƯƠNG
• Bộ GD&ĐT (2018). Chương trình giáo dục phổ thông môn Tin học (Thông tư 32/2018/TT-BGDĐT).
• Anderson, L. W., & Krathwohl, D. R. (2001). A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom's Taxonomy of Educational Objectives. Longman.
• Sách giáo khoa Tin học 8, 10, 11 (Kết nối tri thức / Cánh Diều / Chân trời sáng tạo — tùy bộ sách sử dụng tại địa phương).
• Grover, S., & Pea, R. (2013). Computational thinking in K-12: A review of the state of the field. Educational Researcher, 42(1), 38–43.
• UNESCO (2023). Guidance for generative AI in education and research.
CHƯƠNG 3: THIẾT KẾ HOẠT ĐỘNG GIẢI QUYẾT VẤN ĐỀ TRONG DẠY HỌC TIN HỌC
Thời lượng: 8 tiết (4 tiết lý thuyết + 4 tiết thực hành) Sách giáo khoa tham chiếu: Tin học – Kết nối tri thức với cuộc sống
________________________________________
A. VỊ TRÍ CHƯƠNG TRONG HỌC PHẦN
Chương 1 xây dựng nền tảng lý luận (vấn đề là gì, tư duy tính toán, các mô hình GQVĐ). Chương 2 rèn kỹ năng đọc và giải phẫu bài tập theo 7 chiều phân tích. Chương 3 bước vào nhiệm vụ trung tâm của nghề dạy học: thiết kế — tức là từ kết quả phân tích bài tập (đầu ra Chương 2), tạo ra toàn bộ hệ thống hoạt động học tập giúp học sinh đi từ "chưa biết" đến "giải quyết được vấn đề". Đây là chương dài nhất (8 tiết) và có tính ứng dụng cao nhất của học phần — sản phẩm thực hành cuối chương là bộ thiết kế hoàn chỉnh mà sinh viên có thể mang ra lớp dạy ngay.
________________________________________
B. MỤC TIÊU CHƯƠNG
Sau chương này, sinh viên có thể:
• Vận dụng được quy trình GQVĐ 8 bước như một khung tổ chức xuyên suốt mọi thiết kế hoạt động dạy học.
• Phân tích mục tiêu và nhiệm vụ học tập một cách có hệ thống từ yêu cầu cần đạt của CT GDPT 2018.
• Thiết kế được tình huống có vấn đề kích thích nhận thức học sinh ở đúng mức độ phù hợp.
• Thiết kế được hệ thống câu hỏi gợi mở, scaffold nhiều mức, worksheet có cấu trúc và bài tập phân hóa.
• Tổ chức được hoạt động nhóm và phân hóa học sinh trong bối cảnh GQVĐ Tin học.
• Xác định được thời điểm và mức độ phù hợp để tích hợp AI chatbot vào hoạt động học sinh.
• Hoàn thành một bộ thiết kế hoạt động GQVĐ hoàn chỉnh cho một chủ đề cụ thể trong chương trình Tin học phổ thông.
________________________________________
C. QUY TRÌNH GIẢI QUYẾT VẤN ĐỀ 8 BƯỚC — KHUNG TỔ CHỨC CỦA TOÀN CHƯƠNG
Trước khi đi vào từng mục nội dung, cần thiết lập rõ quy trình GQVĐ 8 bước là trục xương sống mà mọi thiết kế trong chương này đều xoay quanh. Mỗi công cụ thiết kế (câu hỏi, scaffold, worksheet...) đều phục vụ một hoặc nhiều bước trong quy trình này.
BƯỚC 1: ĐỌC ĐỀ
Hiểu yêu cầu bề mặt — xác định được đề bài nói gì
↓
BƯỚC 2: PHÂN TÍCH
Hiểu sâu bên dưới — xác định input, output, ràng buộc ẩn, trường hợp biên
↓
BƯỚC 3: MÔ HÌNH HÓA
Biểu diễn vấn đề bằng ngôn ngữ chính xác hơn — sơ đồ, bảng, ký hiệu toán học,
cấu trúc dữ liệu, mô hình ER, sơ đồ luồng dữ liệu
↓
BƯỚC 4: LẬP KẾ HOẠCH
Xác định chiến lược giải — thuật toán, quy trình thao tác, thứ tự các bước
↓
BƯỚC 5: THỰC HIỆN
Cài đặt kế hoạch — viết code, thao tác phần mềm, xây dựng CSDL, thiết kế web
↓
BƯỚC 6: KIỂM TRA
Đối chiếu kết quả với yêu cầu — chạy thử, kiểm thử, debug, so sánh với test case
↓
BƯỚC 7: ĐÁNH GIÁ
Nhìn lại toàn bộ lời giải — hiệu quả, tính tổng quát, độ phức tạp, khả năng cải tiến
↓
BƯỚC 8: KHÁI QUÁT HÓA
Rút ra bài học tổng quát — mẫu tư duy nào đã dùng, bài toán tương tự nào có thể giải bằng cách này
Vai trò của GV tại mỗi bước khác nhau căn bản: Ở Bước 1–2, GV chủ yếu đặt câu hỏi để học sinh không bỏ qua bước đọc kỹ; Bước 3–4 là bước học sinh hay "bỏ" nhất và cần scaffold nhiều nhất; Bước 5 là bước học sinh hay "sa lầy" kỹ thuật; Bước 6–8 là bước học sinh hay bỏ qua nhất vì nghĩ "xong rồi". Toàn bộ nội dung Chương 3 về bản chất là: làm thế nào để thiết kế hoạt động giúp học sinh đi đủ 8 bước này — không bước nào bị bỏ, không bước nào bị làm thay.
________________________________________
D. NỘI DUNG LÝ THUYẾT (4 tiết)
________________________________________
3.1. Phân tích mục tiêu
Bản chất: Phân tích mục tiêu là bước GV hỏi chính mình: "Sau khi học sinh hoàn thành hoạt động này, họ phải có khả năng làm được gì mà trước đó chưa làm được?" Câu trả lời phải đủ cụ thể để hai GV khác nhau đều đánh giá được kết quả theo cùng một chuẩn.
Ba tầng mục tiêu cần phân tích:
Mục tiêu học tập trong dạy học GQVĐ Tin học cần được nhìn theo ba tầng có quan hệ phụ thuộc. Tầng dưới cùng là mục tiêu kiến thức và kỹ năng — những gì học sinh phải biết và làm được để thực hiện được hoạt động (đã phân tích ở Chương 2). Tầng giữa là mục tiêu quá trình — học sinh phải trải qua những bước tư duy nào trong quá trình GQVĐ, không chỉ đến đích mà còn phải đi đúng đường. Tầng trên cùng là mục tiêu năng lực — sau hoạt động này, năng lực nào trong khung NLa–NLe được phát triển ở mức độ nào.
Tầng mục tiêu Câu hỏi định hướng Ví dụ — Bài toán "Sắp xếp danh sách học sinh theo điểm"
Kiến thức/Kỹ năng Học sinh biết và làm được gì? Biết cú pháp sort()/sorted(), biết lambda, viết được code sắp xếp đa tiêu chí
Quá trình GQVĐ Học sinh trải qua bước tư duy nào? Phân tích tiêu chí sắp xếp (Bước 2), chọn thuật toán phù hợp (Bước 4), kiểm thử với dữ liệu có điểm bằng nhau (Bước 6)
Năng lực Năng lực nào được phát triển? NLc (thiết kế giải pháp), NLa (sử dụng Python IDE), một phần NLd (tìm tài liệu về hàm sort)
Mục tiêu phân hóa — điều thường bị bỏ qua: Ngoài mục tiêu "sàn" (mọi học sinh phải đạt), GV cần xác định mục tiêu "trần" (học sinh khá giỏi có thể đạt thêm) và mục tiêu "hỗ trợ" (học sinh yếu cần đạt tối thiểu điều gì). Ba mức này quyết định cách thiết kế scaffold và bài tập phân hóa (mục 3.5 và 3.10).
Ví dụ phân hóa cho cùng bài toán sắp xếp:
• Mục tiêu sàn: Học sinh sắp xếp được danh sách theo một tiêu chí sử dụng sort().
• Mục tiêu trần: Học sinh sắp xếp được theo đa tiêu chí (điểm giảm dần, nếu bằng thì tên tăng dần) và giải thích được tại sao dùng key=lambda.
• Mục tiêu hỗ trợ: Học sinh điền đúng tham số vào template code có sẵn để thực hiện được sắp xếp đơn giản.
Liên kết với quy trình 8 bước: Mục tiêu quá trình cần chỉ rõ: trong hoạt động này, học sinh tự thực hiện bước nào, được hỗ trợ bước nào, và GV làm mẫu bước nào. Đây là quyết định sư phạm quan trọng nhất của toàn bộ thiết kế — và nó phải được ghi rõ trong kế hoạch bài dạy, không phải để mặc định diễn ra tùy hứng.
________________________________________
3.2. Phân tích nhiệm vụ (Task Analysis)
Bản chất: Phân tích nhiệm vụ là kỹ thuật "giải phẫu" một nhiệm vụ học tập phức tạp thành các nhiệm vụ con có thứ tự, xác định các điều kiện tiên quyết và mối quan hệ phụ thuộc giữa chúng. Đây là bước nối cầu giữa phân tích mục tiêu (biết mình muốn học sinh đến đâu) và thiết kế hoạt động (biết mình cần đưa học sinh đi qua những chặng nào).
Quy trình phân tích nhiệm vụ (5 bước):
Bước 1 — Xác định nhiệm vụ đầu cuối (terminal task): Viết rõ sản phẩm cuối cùng học sinh cần tạo ra. Ví dụ: "Học sinh viết được chương trình Python quản lý danh sách học sinh: thêm, xóa, tìm kiếm và sắp xếp."
Bước 2 — Phân rã thành nhiệm vụ con (subtask decomposition): Liệt kê tất cả các nhiệm vụ con mà học sinh phải hoàn thành để đạt được nhiệm vụ đầu cuối. Không bỏ sót — kể cả những bước tưởng như "hiển nhiên".
Bước 3 — Xác định quan hệ phụ thuộc (dependency mapping): Nhiệm vụ con nào phải hoàn thành trước để nhiệm vụ con khác mới thực hiện được? Vẽ sơ đồ phụ thuộc.
Bước 4 — Xác định điều kiện tiên quyết (prerequisite identification): Nhiệm vụ con nào đòi hỏi kiến thức/kỹ năng học sinh đã có từ trước (không cần dạy trong hoạt động này)?
Bước 5 — Xác định điểm khó (difficulty hotspot): Nhiệm vụ con nào học sinh thường gặp khó khăn nhất? Đây là nơi GV cần thiết kế scaffold dày nhất.
Ví dụ minh họa — Phân tích nhiệm vụ: "Viết chương trình kiểm tra số nguyên tố" (Tin học 10, Kết nối tri thức):
NHIỆM VỤ ĐẦU CUỐI:
Viết chương trình Python nhập số nguyên n,
in "Nguyên tố" hoặc "Không nguyên tố"
PHÂN RÃ NHIỆM VỤ CON:
├── MT1: Hiểu định nghĩa số nguyên tố (tiên quyết — đã học từ Toán)
├── MT2: Xác định điều kiện kiểm tra (n < 2 → không nguyên tố)
│ └── MT2a: Xử lý trường hợp đặc biệt n=0, n=1, n=2
├── MT3: Lựa chọn phạm vi kiểm tra ước (từ 2 đến √n hoặc đến n-1)
│ └── MT3a: Hiểu tại sao chỉ cần kiểm tra đến √n [ĐIỂM KHÓ]
├── MT4: Cài đặt vòng lặp kiểm tra ước
│ ├── MT4a: Viết vòng lặp for với range phù hợp
│ └── MT4b: Dùng toán tử % để kiểm tra chia hết
├── MT5: Xử lý điều kiện thoát sớm (break khi tìm thấy ước) [ĐIỂM KHÓ]
├── MT6: Hiển thị kết quả đúng dựa trên biến cờ (flag) [ĐIỂM KHÓ]
└── MT7: Kiểm thử với test case bao phủ edge case
├── n=2 (nguyên tố nhỏ nhất)
├── n=1 (không nguyên tố)
├── n=0, n=-5 (trường hợp âm)
└── n=97 (nguyên tố lớn)
QUAN HỆ PHỤ THUỘC: MT1 → MT2 → MT3 → MT4 → MT5 → MT6 → MT7
ĐIỂM KHÓ: MT3a (tại sao √n), MT5 (break logic), MT6 (flag pattern)
Vai trò của phân tích nhiệm vụ trong thiết kế: Sau khi có sơ đồ phân tích nhiệm vụ, GV biết chính xác: (1) cần thiết kế scaffold cho những điểm khó nào (mục 3.6), (2) nên chia nhỏ nhiệm vụ như thế nào để học sinh không bị choáng ngợp (mục 3.8), (3) câu hỏi gợi mở cần đặt ra tại những bước chuyển tiếp nào (mục 3.5). Không có phân tích nhiệm vụ, mọi thiết kế phía sau chỉ là phỏng đoán.
________________________________________
3.3. Thiết kế tình huống có vấn đề
Bản chất và vai trò: Tình huống có vấn đề (THCVĐ) là điểm khởi đầu của toàn bộ hoạt động GQVĐ — là "bệ phóng" nhận thức. Một THCVĐ tốt phải tạo ra được "khoảng cách nhận thức" (cognitive gap): học sinh nhận ra rằng mình muốn đến đích nhưng chưa có sẵn con đường để đến — đây chính là định nghĩa về vấn đề đã học ở Chương 1. Nếu THCVĐ quá dễ (học sinh đã biết cách làm ngay), không có vấn đề gì cần giải quyết. Nếu quá khó (học sinh không có kiến thức nền để tiếp cận), không có động lực để bắt đầu.
Bốn tiêu chí của một THCVĐ tốt trong Tin học:
Tiêu chí Mô tả Dấu hiệu vi phạm
Tính vừa sức Nằm trong "vùng phát triển gần nhất" (ZPD) của học sinh — không quá dễ, không quá khó HS giải ngay trong 1 phút hoặc HS không biết bắt đầu từ đâu
Tính có ý nghĩa Học sinh thấy lý do tại sao cần giải quyết — có bối cảnh thực tế hoặc trí tuệ hấp dẫn HS hỏi "Học cái này để làm gì?"
Tính mở vừa phải Có nhiều hơn một cách tiếp cận, nhưng không quá mơ hồ đến mức không biết bắt đầu Chỉ có đúng một đáp án hiển nhiên, hoặc không có gợi ý nào về hướng đi
Tính kích thích tư duy Kích hoạt được ít nhất 2 trong 4 thành phần tư duy tính toán THCVĐ chỉ đòi hỏi nhớ lại và áp dụng máy móc
Sáu dạng tình huống có vấn đề trong Tin học:
Dạng 1 — Tình huống thực tế cần tin học hóa (Real-world Informatization): Xuất phát từ một vấn đề thực tế học sinh quen thuộc, đặt câu hỏi: "Làm thế nào để giải quyết điều này bằng máy tính?"
Ví dụ (Lớp 10 — Chủ đề vòng lặp): "Thủ quỹ lớp em phải tính tổng tiền quỹ thu được từ 40 học sinh, mỗi người đóng số tiền khác nhau. Mỗi tháng đều phải tính lại từ đầu. Làm thế nào để viết một chương trình giúp thủ quỹ làm việc này nhanh và chính xác hơn?"
Dạng 2 — Tình huống mâu thuẫn nhận thức (Cognitive Conflict): Trình bày một kết quả hoặc hiện tượng bất ngờ, mâu thuẫn với hiểu biết hiện tại của học sinh, buộc học sinh phải suy nghĩ lại.
Ví dụ (Lớp 10 — Chủ đề kiểu dữ liệu): GV chạy đoạn code: print(0.1 + 0.2 == 0.3) và màn hình hiện ra False. GV hỏi: "Tại sao máy tính lại nói 0.1 + 0.2 khác 0.3? Máy tính bị hỏng không? Hay có điều gì đó về cách máy tính lưu trữ số mà chúng ta chưa biết?"
Dạng 3 — Tình huống thiếu dữ liệu (Incomplete Information): Cung cấp một vấn đề nhưng thiếu thông tin, buộc học sinh phải xác định mình cần thêm gì và đặt câu hỏi để bổ sung.
Ví dụ (Lớp 11 — Chủ đề CSDL): "Trường em muốn xây dựng phần mềm quản lý mượn-trả sách thư viện. Em hãy bắt đầu thiết kế." Học sinh lập tức nhận ra: thiếu thông tin — cần biết thư viện có bao nhiêu loại sách, một cuốn có bao nhiêu bản, một học sinh được mượn tối đa mấy cuốn... Việc học sinh tự phát hiện ra những câu hỏi này chính là Bước 2 (Phân tích) đang diễn ra.
Dạng 4 — Tình huống so sánh phương án (Solution Comparison): Trình bày hai hoặc nhiều cách giải đã có sẵn, yêu cầu học sinh phân tích và lựa chọn cách tốt hơn theo tiêu chí cụ thể.
Ví dụ (Lớp 10 — Chủ đề thuật toán): "Đây là hai chương trình tìm phần tử lớn nhất trong mảng 1 triệu phần tử — một dùng duyệt tuyến tính, một dùng chia đôi tìm kiếm. Em hãy đo thời gian chạy của cả hai và giải thích tại sao lại có sự khác biệt đó."
Dạng 5 — Tình huống sản phẩm có lỗi (Buggy Product): Cung cấp một sản phẩm/chương trình đã có nhưng hoạt động chưa đúng hoặc chưa đủ tốt, yêu cầu học sinh phân tích và cải thiện.
Ví dụ (Lớp 10 — Chủ đề lập trình): "Bạn An đã viết chương trình kiểm tra số nguyên tố nhưng chương trình cho kết quả sai với một số trường hợp. Đây là code của bạn An. Em hãy tìm ra lỗi, giải thích nguyên nhân và sửa lại."
Dạng 6 — Tình huống mở rộng (Extension Challenge): Từ một bài toán học sinh đã giải được, đặt thêm ràng buộc hoặc yêu cầu tổng quát hóa.
Ví dụ (Lớp 10): "Em đã viết được chương trình kiểm tra một số có phải số nguyên tố không. Bây giờ, làm thế nào để tìm tất cả số nguyên tố từ 2 đến N với N có thể lên đến 1 triệu, mà chương trình vẫn chạy trong vòng 1 giây?"
Quy trình thiết kế THCVĐ (5 bước thực hành):
1. Xác định kiến thức mục tiêu cần hình thành (từ phân tích mục tiêu, mục 3.1).
2. Xác định kiến thức nền học sinh đã có (để đảm bảo tính vừa sức).
3. Chọn dạng tình huống phù hợp trong 6 dạng trên.
4. Tìm hoặc tạo bối cảnh có ý nghĩa với học sinh (gần gũi, thực tế, có tính kích thích).
5. Viết câu hỏi kích hoạt — câu hỏi mở đầu đặt ra vấn đề mà học sinh chưa biết cách giải nhưng muốn tìm hiểu.
________________________________________
3.4. Thiết kế bài tập trong hoạt động GQVĐ
Phân biệt bài tập GQVĐ với bài tập luyện tập thông thường:
Bài tập GQVĐ không đơn giản là bài tập khó hơn. Sự khác biệt nằm ở chỗ: bài tập luyện tập yêu cầu học sinh áp dụng thuật giải đã có sẵn vào tình huống quen thuộc; bài tập GQVĐ yêu cầu học sinh tự xây dựng thuật giải cho tình huống chưa từng gặp. Ranh giới này phụ thuộc vào trình độ học sinh — cùng một bài toán có thể là GQVĐ với học sinh yếu nhưng chỉ là luyện tập với học sinh giỏi.
Bốn đặc tính cần có của bài tập GQVĐ trong Tin học:
Tính vấn đề thực sự (genuine problematicity): Học sinh không thể giải ngay khi đọc xong đề — cần phân tích, lập kế hoạch, thử nghiệm. Nếu học sinh làm đúng ngay lần đầu mà không phải suy nghĩ gì đáng kể, đó là bài tập luyện tập.
Tính bối cảnh (contextuality): Bài tập được đặt trong một bối cảnh cụ thể, có ý nghĩa — không phải "tính tổng dãy số" mà là "tính tổng doanh thu tháng cho cửa hàng của bố em". Bối cảnh không phải là trang trí — nó cung cấp ngữ nghĩa giúp học sinh hiểu sâu hơn về ý nghĩa của từng bước giải.
Tính nhiều bước (multi-step nature): Bài tập đòi hỏi ít nhất 3–4 bước tư duy riêng biệt, phù hợp với quy trình 8 bước GQVĐ. Bài tập một bước (dù khó đến đâu) không phải là bài tập GQVĐ theo nghĩa sư phạm.
Tính sản phẩm (product orientation): Học sinh tạo ra một sản phẩm cụ thể — không phải chỉ "trả lời câu hỏi" mà là "tạo ra thứ gì đó hoạt động được": chương trình chạy đúng, sơ đồ CSDL hoàn chỉnh, trang web hiển thị đúng, báo cáo phân tích dữ liệu có căn cứ.
Ma trận thiết kế bài tập — giao điểm giữa nhóm nội dung và mức độ Bloom:
Nhớ/Hiểu Vận dụng Phân tích Đánh giá Sáng tạo
Khái niệm Định nghĩa, so sánh khái niệm Phân loại ví dụ cụ thể Phân tích mối quan hệ giữa các khái niệm Nhận xét định nghĩa của người khác Tạo ví dụ minh họa mới
Thuật toán Mô tả lại thuật toán Áp dụng thuật toán cho input mới So sánh hai thuật toán cùng bài toán Chọn thuật toán tối ưu có lập luận Thiết kế thuật toán mới
Lập trình Đọc và giải thích code Viết code theo thuật toán cho sẵn Tìm và phân tích lỗi trong code Đánh giá chất lượng code theo tiêu chí Thiết kế và cài đặt giải pháp từ đầu
CSDL Mô tả cấu trúc bảng Viết câu truy vấn SELECT cơ bản Phân tích thiết kế schema Đánh giá hai schema, chọn tốt hơn Thiết kế CSDL cho bài toán thực tế
Nguyên tắc "bài tập mẹ — bài tập con": Thay vì thiết kế nhiều bài tập độc lập, GV nên thiết kế một "bài tập mẹ" phức tạp và phân rã thành các "bài tập con" có thứ tự. Mỗi bài tập con giải quyết một nhiệm vụ con trong phân tích nhiệm vụ (mục 3.2), và kết quả của bài tập con trước là đầu vào của bài tập con tiếp theo. Cách này giúp học sinh thấy rõ tiến trình và cảm nhận được sự tích lũy dần dần hướng đến mục tiêu lớn.
Ví dụ (Lớp 10 — Bài tập mẹ: Chương trình quản lý điểm lớp học):
• Bài tập con 1: Viết code nhập điểm của một học sinh (test: in ra giá trị vừa nhập).
• Bài tập con 2: Mở rộng để nhập điểm cho cả lớp (dùng vòng lặp, lưu vào danh sách).
• Bài tập con 3: Tính điểm trung bình và tìm điểm cao nhất.
• Bài tập con 4: Phân loại học sinh và đếm số lượng mỗi loại.
• Bài tập con 5 (nâng cao): Sắp xếp danh sách và xuất ra file kết quả.
________________________________________
3.5. Thiết kế hệ thống câu hỏi gợi mở
Bản chất: Câu hỏi gợi mở (guiding questions) là công cụ sư phạm chủ đạo của GV trong giờ GQVĐ — thay thế cho việc giải thích trực tiếp. Một câu hỏi gợi mở tốt không dẫn học sinh thẳng đến đáp án mà dẫn học sinh đến bước tư duy tiếp theo mà học sinh cần tự thực hiện. Sự khác biệt này rất tinh tế nhưng quyết định toàn bộ chất lượng học tập: giải thích trực tiếp tạo ra sự hiểu biết thụ động; câu hỏi gợi mở tạo ra sự khám phá chủ động.
Ba tầng câu hỏi cần thiết kế (tương ứng với ba mức hỗ trợ):
Tầng 1 — Câu hỏi định hướng (Orienting questions): Giúp học sinh xác định đúng hướng khi bắt đầu hoặc khi bị lạc. Thường áp dụng ở Bước 1–2 của quy trình GQVĐ.
Đặc điểm: câu hỏi về "cái gì" và "để làm gì". Ví dụ:
• "Đề bài yêu cầu đầu vào là gì, đầu ra là gì?"
• "Ràng buộc nào của bài toán mà em cho là quan trọng nhất?"
• "Em hiểu yêu cầu 'kết thúc khi nhập 0' nghĩa là thế nào?"
Tầng 2 — Câu hỏi khám phá (Exploratory questions): Giúp học sinh đi sâu hơn vào phân tích và lập kế hoạch. Thường áp dụng ở Bước 3–4.
Đặc điểm: câu hỏi về "như thế nào" và "tại sao". Ví dụ:
• "Em nghĩ sẽ cần dùng cấu trúc dữ liệu gì để lưu thông tin này? Tại sao chọn danh sách thay vì biến riêng lẻ?"
• "Nếu em vẽ sơ đồ khối cho thuật toán này, bước nào cần có điều kiện rẽ nhánh?"
• "Có bao nhiêu trường hợp cần xử lý khác nhau trong bài này?"
Tầng 3 — Câu hỏi kiểm chứng (Verification questions): Giúp học sinh nhìn lại và đánh giá kết quả. Thường áp dụng ở Bước 6–8.
Đặc điểm: câu hỏi về "đã đúng chưa" và "còn cách nào khác không". Ví dụ:
• "Chạy thử với input -5, chương trình của em làm gì? Đó có phải là hành vi mong muốn không?"
• "Nếu danh sách có 1 triệu phần tử, thuật toán của em còn hoạt động ổn không?"
• "Em có thể viết lại đoạn này ngắn gọn hơn không mà vẫn đúng?"
Ma trận câu hỏi gợi mở theo bước GQVĐ và loại bài tập:
Bước GQVĐ Câu hỏi gợi mở mẫu — Lập trình Câu hỏi gợi mở mẫu — CSDL
1. Đọc đề "Input của bài này là kiểu dữ liệu gì?" "Bài toán đang mô tả hệ thống nào trong thực tế?"
2. Phân tích "Trường hợp nào là trường hợp đặc biệt cần xử lý riêng?" "Những thực thể nào xuất hiện trong mô tả bài toán?"
3. Mô hình hóa "Em dùng cấu trúc dữ liệu nào để biểu diễn thông tin này?" "Giữa học sinh và môn học có quan hệ một-nhiều hay nhiều-nhiều?"
4. Lập kế hoạch "Hãy viết giả mã 3–5 bước trước khi viết code thật" "Em tạo bảng nào trước, bảng nào sau? Tại sao?"
5. Thực hiện "Dòng này em muốn làm gì? Cú pháp đúng của nó là gì?" "Mệnh đề JOIN ở đây nối bảng nào với bảng nào theo điều kiện gì?"
6. Kiểm tra "Chạy với bộ test case nào em chưa thử?" "Thêm một bản ghi học sinh không có môn học nào — truy vấn còn đúng không?"
7. Đánh giá "Vòng lặp này chạy bao nhiêu lần? Có cách nào giảm xuống không?" "Schema này đã đạt chuẩn 3NF chưa? Bằng chứng?"
8. Khái quát hóa "Pattern 'accumulator' này em còn gặp ở bài toán nào khác?" "Nguyên tắc thiết kế nào em rút ra từ bài toán này?"
Kỹ thuật "Wait Time" (thời gian chờ): Sau khi đặt câu hỏi gợi mở, GV phải im lặng ít nhất 5–7 giây trước khi gọi học sinh trả lời hoặc đặt câu hỏi khác. Nghiên cứu giáo dục (Rowe, 1986) cho thấy thời gian chờ dài hơn dẫn đến câu trả lời dài hơn, sâu hơn và nhiều học sinh tham gia hơn. Đây là một trong những kỹ năng sư phạm khó nhất nhưng có tác động lớn nhất trong giờ GQVĐ — GV mới thường phá vỡ im lặng quá sớm vì cảm thấy không thoải mái.
________________________________________
3.6. Thiết kế Scaffold (Giàn giáo hỗ trợ)
Bản chất: Scaffold (giàn giáo) trong dạy học là hệ thống hỗ trợ tạm thời giúp học sinh hoàn thành được nhiệm vụ ở mức cao hơn khả năng độc lập hiện tại của mình — với mục tiêu cuối cùng là gỡ bỏ dần sự hỗ trợ khi học sinh tự làm được. Tên gọi "giàn giáo" gợi lên đúng bản chất: giàn giáo xây dựng là phương tiện tạm thời, không phải phần vĩnh cửu của công trình.
Trong dạy học Tin học, scaffold đặc biệt quan trọng vì: nhiều nhiệm vụ (viết code, thiết kế CSDL) vừa đòi hỏi tư duy logic cao vừa đòi hỏi kỹ năng cú pháp cụ thể — học sinh yếu thường bị "kẹt" ở lớp cú pháp mà không bao giờ tiếp cận được lớp tư duy logic bên trên. Scaffold giúp "nâng đỡ" lớp cú pháp để học sinh có thể tập trung tư duy vào lớp logic.
Năm hình thức scaffold phổ biến trong dạy học Tin học:
a) Code template (Mẫu code có chỗ trống):
GV cung cấp cấu trúc chương trình với phần tư duy logic để trống, học sinh chỉ cần điền vào. Phù hợp cho học sinh mới bắt đầu hoặc khi bài toán mới ở điểm khó về cú pháp.
# Scaffold mức 1 — Nhiều gợi ý, ít chỗ trống
tong = 0
n = int(input("Nhập số: "))
while n != 0:
if _______: # Điền điều kiện: khi nào thì cộng vào tổng?
tong = tong + n
n = int(input("Nhập số tiếp theo: "))
print("Tổng các số dương:", _______) # Điền tên biến chứa kết quả
# Scaffold mức 2 — Ít gợi ý hơn, nhiều chỗ trống hơn
tong = _______
n = int(input("Nhập số: "))
while _______:
if n > 0:
_______
n = _______
print("Tổng:", tong)
# Scaffold mức 3 — Chỉ có cấu trúc, không có gợi ý
tong = ___
n = ___
while ___:
if ___:
___
___
print(___)
b) Câu hỏi dẫn dắt có cấu trúc (Structured guiding questions):
Một chuỗi câu hỏi được thiết kế theo thứ tự, mỗi câu hỏi dẫn đến câu hỏi tiếp theo, cùng dẫn đến lời giải. Khác với câu hỏi gợi mở tự do ở mục 3.5, đây là scaffold vì chuỗi câu hỏi được viết sẵn và học sinh có thể tự đọc và làm theo mà không cần GV có mặt.
Ví dụ (scaffold cho bài kiểm tra số nguyên tố):
1. Định nghĩa số nguyên tố là số có đúng 2 ước. Các ước đó là gì?
2. Để kiểm tra n có ước nào từ 2 đến n-1 không, em cần duyệt qua những số nào?
3. Nếu tìm được một ước (n % i == 0), em cần tiếp tục kiểm tra các số tiếp theo không? Tại sao?
4. Sau khi duyệt xong vòng lặp mà không tìm thấy ước nào, n là số nguyên tố hay không?
5. Trường hợp đặc biệt n=0, n=1, n=2 cần xử lý thế nào?
c) Ví dụ tương tự đã giải (Worked example):
Cung cấp một bài toán tương tự đã được giải hoàn chỉnh (có giải thích từng bước), học sinh tham chiếu để giải bài mới. Hiệu quả nhất khi kết hợp với yêu cầu học sinh giải thích sự tương tự và khác biệt giữa ví dụ mẫu và bài mới — buộc học sinh tư duy thay vì chỉ sao chép.
Ví dụ: "Đây là code giải bài 'đếm số chẵn trong dãy'. Bài em cần giải là 'tính tổng số dương trong dãy'. Hãy chỉ ra: (1) điểm giống nhau về cấu trúc, (2) điểm khác nhau cần thay đổi, rồi mới viết code mới."
d) Checklist kiểm tra (Self-check scaffold):
Danh sách các điểm cần kiểm tra trước khi nộp bài. Scaffold này đặc biệt hiệu quả cho Bước 6 (Kiểm tra) và Bước 7 (Đánh giá) — những bước học sinh thường bỏ qua nhất.
Ví dụ checklist cho bài lập trình Python:
• [ ] Chương trình chạy không có lỗi cú pháp.
• [ ] Chạy đúng với input thông thường (test case cơ bản).
• [ ] Chạy đúng với input đặc biệt (số âm, số 0, danh sách rỗng...).
• [ ] Biến và hàm có tên rõ nghĩa (không dùng a, b, x).
• [ ] Có chú thích (comment) giải thích những đoạn code phức tạp.
• [ ] Kết quả được in ra đúng định dạng yêu cầu.
e) Sơ đồ tư duy / Công cụ trực quan hóa (Visual scaffold):
Sơ đồ, bảng, biểu đồ giúp học sinh nhìn thấy cấu trúc của vấn đề trước khi cài đặt. Đặc biệt hiệu quả cho Bước 3 (Mô hình hóa) — giai đoạn học sinh hay bỏ qua để "nhảy thẳng vào code".
Ví dụ: Trước khi viết code quản lý danh sách học sinh, yêu cầu học sinh điền vào bảng:
Thông tin cần lưu Kiểu dữ liệu phù hợp Tên biến/cấu trúc
Họ tên học sinh str ?
Điểm Toán float ?
Danh sách tất cả học sinh list of dict ?
Nguyên tắc "dỡ giàn giáo dần" (gradual release of responsibility):
Scaffold phải được thiết kế theo lộ trình: học sinh mới bắt đầu nhận nhiều hỗ trợ, dần dần GV rút hỗ trợ đi khi học sinh thành thạo hơn. Không có scaffold nào nên tồn tại mãi mãi — nếu học sinh vẫn cần template sau 5 bài tập, đó là dấu hiệu có điều gì đó sai trong chuỗi thiết kế.
Bài 1: Code template mức 1 (nhiều gợi ý)
↓
Bài 2: Code template mức 2 (ít gợi ý hơn)
↓
Bài 3: Chỉ có checklist
↓
Bài 4: Tự do hoàn toàn
________________________________________
3.7. Thiết kế Worksheet
Bản chất: Worksheet (phiếu học tập) là công cụ tổ chức hoạt động học tập trên giấy hoặc màn hình, hướng dẫn học sinh đi qua quy trình GQVĐ một cách có cấu trúc. Worksheet khác với đề bài đơn giản ở chỗ: worksheet không chỉ hỏi kết quả mà hướng dẫn quá trình — học sinh được dẫn dắt qua từng bước tư duy và ghi lại suy nghĩ của mình ở mỗi bước.
Bảy thành phần của một Worksheet GQVĐ hoàn chỉnh:
Phần 1 — Bối cảnh và vấn đề: Mô tả tình huống có vấn đề đủ chi tiết để học sinh hiểu ngữ cảnh. Không phải chỉ là "đề bài" mà là "câu chuyện" có đủ thông tin nền.
Phần 2 — Đọc đề và phân tích (Bước 1–2): Các ô trống có cấu trúc để học sinh ghi lại kết quả phân tích:
• Input là gì? Kiểu dữ liệu? Ràng buộc?
• Output cần tạo ra là gì?
• Các trường hợp đặc biệt cần xử lý?
• Điều gì em chưa rõ cần hỏi thêm?
Phần 3 — Mô hình hóa (Bước 3): Không gian để học sinh vẽ sơ đồ, viết ký hiệu, phác thảo cấu trúc dữ liệu, hoặc mô tả bài toán theo ngôn ngữ chính xác hơn ngôn ngữ tự nhiên.
Phần 4 — Lập kế hoạch (Bước 4): Ô trống để viết thuật toán/giả mã/sơ đồ khối. Có thể có scaffold ở đây (ví dụ: các bước đầu đã cho sẵn, học sinh điền tiếp).
Phần 5 — Thực hiện (Bước 5): Chỗ học sinh viết code (trong môi trường trên máy) hoặc ghi lại kết quả thực hành. Trong worksheet trên giấy, phần này thường là "ghi địa chỉ file/link" và "chụp màn hình kết quả".
Phần 6 — Kiểm tra (Bước 6): Bảng test case với cột "Input dự kiến", "Output mong đợi" và "Output thực tế" để học sinh tự điền sau khi chạy chương trình.
Input dự kiến Output mong đợi Output thực tế Đúng/Sai
5, 3, -1, 0 Tổng = 8
-5, -3, 0 Tổng = 0
0 Tổng = 0
Phần 7 — Đánh giá và khái quát hóa (Bước 7–8): Câu hỏi phản tư mở:
• Em gặp khó khăn lớn nhất ở bước nào? Tại sao?
• Nếu làm lại, em sẽ làm khác đi điều gì?
• Bài toán này có điểm gì giống với những bài đã làm trước?
• Bài toán này dạy em pattern tư duy gì có thể dùng lại sau này?
Nguyên tắc thiết kế worksheet hiệu quả:
Worksheet không phải là bài kiểm tra — không nên có quá nhiều yêu cầu bắt buộc làm học sinh lo lắng. Các phần mô hình hóa và phân tích nên có đủ không gian để học sinh vẽ, gạch, viết tự do. Phần phản tư (Bước 7–8) là phần nhiều GV bỏ qua nhất — nhưng đây lại là phần có giá trị học tập lâu dài nhất. Worksheet nên có thể hoàn thành trong 1 tiết học; nếu quá dài, học sinh sẽ bỏ qua phần phản tư để kịp nộp.
________________________________________
3.8. Chia nhỏ nhiệm vụ học tập (Task Chunking)
Bản chất: Chia nhỏ nhiệm vụ là kỹ thuật phân rã một nhiệm vụ phức tạp thành các phần nhỏ hơn, có thể hoàn thành được trong thời gian ngắn, với kết quả kiểm tra được ngay. Đây là sự hiện thực hóa của thành phần Phân rã (Decomposition) trong tư duy tính toán — nhưng ở đây áp dụng cho việc tổ chức hoạt động dạy học, không phải cho bản thân bài toán.
Tại sao chia nhỏ nhiệm vụ quan trọng trong Tin học: Một chương trình Python 50 dòng với học sinh mới học lập trình là một nhiệm vụ khổng lồ — học sinh không biết bắt đầu từ đâu và dễ bỏ cuộc. Cùng chương trình đó, nếu được chia thành 6 bài tập con, mỗi bài 5–10 dòng code, học sinh có thể tiếp cận từng bước và cảm nhận được tiến trình.
Ba chiến lược chia nhỏ nhiệm vụ:
Chiến lược 1 — Chia theo chức năng (Functional decomposition): Chia nhiệm vụ theo các chức năng độc lập của sản phẩm cuối. Ví dụ: chương trình quản lý điểm = chức năng nhập điểm + chức năng tính thống kê + chức năng hiển thị + chức năng tìm kiếm. Mỗi chức năng là một nhiệm vụ con.
Chiến lược 2 — Chia theo mức độ phức tạp tăng dần (Complexity escalation): Bắt đầu với phiên bản đơn giản nhất của bài toán, sau đó dần dần thêm ràng buộc và yêu cầu.
Ví dụ (Bài toán quản lý thư viện):
• Chunk 1: Nhập và in thông tin một cuốn sách.
• Chunk 2: Nhập và in thông tin nhiều cuốn sách (dùng danh sách).
• Chunk 3: Tìm kiếm sách theo tên.
• Chunk 4: Thêm và xóa sách khỏi danh sách.
• Chunk 5: Lưu danh sách ra file và đọc lại.
Chiến lược 3 — Chia theo giai đoạn GQVĐ (Process decomposition): Mỗi chunk tương ứng với một hoặc hai bước trong quy trình 8 bước. Cho phép GV kiểm tra và phản hồi sau mỗi chunk trước khi học sinh chuyển sang bước tiếp theo — đặc biệt quan trọng để phát hiện hiểu lầm sớm.
Kỹ thuật "Milestone checkpoint": Sau mỗi chunk, GV thiết kế một "trạm kiểm tra" nhỏ — có thể là một câu hỏi nhanh, một yêu cầu chạy thử và chụp màn hình, hoặc giải thích miệng cho bạn bên cạnh. Checkpoint này giúp: (1) học sinh tự xác nhận mình đã hiểu trước khi tiếp tục; (2) GV phát hiện nhóm học sinh cần hỗ trợ trước khi cả lớp tiến quá xa.
________________________________________
3.9. Thiết kế hoạt động nhóm
Bản chất và điều kiện: Hoạt động nhóm trong GQVĐ Tin học không phải là "chia nhóm để học sinh ngồi cùng nhau" — đó chỉ là ngồi nhóm, không phải học nhóm. Hoạt động nhóm thực sự đòi hỏi: nhiệm vụ có tính cộng tác (không một người nào có thể hoàn thành một mình), vai trò phân công rõ ràng, và sản phẩm chung phản ánh đóng góp của tất cả thành viên.
Bốn mô hình tổ chức nhóm phù hợp với GQVĐ Tin học:
Mô hình 1 — Pair Programming (Lập trình đôi): Hai học sinh chia vai: Driver (gõ code, tập trung vào cú pháp dòng đang viết) và Navigator (quan sát toàn bộ, phát hiện lỗi logic, gợi ý bước tiếp theo). Luân phiên vai sau mỗi 10–15 phút.
Đây là mô hình phù hợp nhất với bài tập lập trình vì: học sinh yếu được hỗ trợ tự nhiên từ bạn Navigator, học sinh giỏi củng cố tư duy qua việc giải thích, lỗi được phát hiện sớm hơn so với làm cá nhân. GV cần hướng dẫn rõ: Navigator không được cầm tay Driver gõ, Navigator chỉ được chỉ vào màn hình và đặt câu hỏi.
Mô hình 2 — Jigsaw GQVĐ: Bài toán phức tạp được chia thành các phần độc lập, mỗi thành viên nhóm chuyên sâu vào một phần, sau đó chia sẻ lại với cả nhóm để ghép thành lời giải tổng thể.
Ví dụ (Thiết kế CSDL thư viện):
• Thành viên A: Thiết kế bảng Sach và các quan hệ.
• Thành viên B: Thiết kế bảng DocGia và TheMuon.
• Thành viên C: Viết các câu truy vấn cơ bản.
• Thành viên D: Thiết kế giao diện nhập liệu đơn giản. Cả nhóm cùng ghép và kiểm tra tính nhất quán của thiết kế tổng thể.
Mô hình 3 — Nhóm chuyên gia — Nhóm home: Học sinh ban đầu ở "nhóm home" (nhóm hỗn hợp trình độ), sau đó tách ra thành "nhóm chuyên gia" (nhóm cùng trình độ / cùng nhiệm vụ) để đi sâu vào một phần, rồi quay về nhóm home để chia sẻ.
Phù hợp với tiết ôn tập (như đã trình bày ở Chương Tổ chức dạy học) và các hoạt động GQVĐ nhiều giai đoạn.
Mô hình 4 — Nhóm dự án (Project team): Nhóm 3–4 học sinh cùng nhau hoàn thành một dự án nhiều tiết, có phân công vai trò cố định và rõ ràng: Trưởng nhóm (điều phối, theo dõi tiến độ), Lập trình viên (viết code), Tester (thiết kế và chạy test case), Báo cáo viên (viết tài liệu và trình bày).
Thiết kế nhiệm vụ nhóm có cấu trúc: Nhiệm vụ nhóm cần được thiết kế sao cho: (1) có sản phẩm chung rõ ràng mà không ai trong nhóm có thể hoàn thành một mình; (2) đóng góp của từng thành viên có thể nhìn thấy và đánh giá được; (3) quá trình thảo luận và quyết định được ghi chép lại (thông qua worksheet nhóm hoặc công cụ cộng tác số như Google Docs).
________________________________________
3.10. Phân hóa học sinh trong hoạt động GQVĐ
Bản chất: Phân hóa (differentiation) không có nghĩa là "ra đề khó hơn cho học sinh giỏi và đề dễ hơn cho học sinh yếu". Phân hóa đúng nghĩa là thiết kế các con đường học tập khác nhau, đều dẫn đến cùng mục tiêu học tập cốt lõi, nhưng với mức độ hỗ trợ và độ phức tạp phù hợp với xuất phát điểm của từng học sinh.
Ba chiều phân hóa có thể thiết kế:
Phân hóa đầu vào (Input differentiation): Cung cấp cùng bài tập nhưng với các mức scaffold khác nhau — học sinh yếu nhận code template mức 1, học sinh trung bình nhận câu hỏi dẫn dắt, học sinh giỏi nhận đề bài trần không có hỗ trợ.
Phân hóa quá trình (Process differentiation): Tổ chức các hoạt động học tập khác nhau cho các nhóm khác nhau — nhóm yếu làm việc với GV trực tiếp tại "trạm hướng dẫn", nhóm trung bình làm việc theo nhóm với bài tập chuẩn, nhóm giỏi tự nghiên cứu và thực hiện bài tập mở rộng.
Phân hóa đầu ra (Output differentiation): Học sinh được phép thể hiện kết quả học tập theo nhiều hình thức — học sinh yếu có thể nộp bài tập con 1–3, học sinh trung bình nộp đầy đủ bài tập con, học sinh giỏi nộp thêm bài mở rộng hoặc viết giải thích về phương án tối ưu hơn.
Công cụ phân hóa thực tế — Bảng lựa chọn (Choice board):
Thay vì GV quyết định ai làm gì, học sinh tự lựa chọn nhiệm vụ từ một "bảng lựa chọn" có nhiều mức độ. Điều này tôn trọng sự tự chủ của học sinh và thường tạo ra động lực cao hơn việc bị phân vào nhóm "yếu" một cách công khai.
Ví dụ Choice board (ôn tập Python vòng lặp):
Mức cơ bản Mức trung bình Mức nâng cao
Hoàn thành code template đã cho sẵn 70% Viết chương trình in bảng cửu chương theo yêu cầu Thiết kế và cài đặt chương trình vẽ hình tam giác bằng ký tự, với n do người dùng nhập
Lưu ý quan trọng về phân hóa trong phòng máy: Phân hóa trong môi trường phòng máy cần tránh "cô lập nhóm yếu" — việc nhóm yếu luôn ngồi làm bài dễ hơn trong khi nhóm giỏi được làm bài thú vị hơn có thể dẫn đến sự phân tầng xã hội trong lớp. Thiết kế phân hóa tốt nhất là khi học sinh không nhận ra mình đang được "phân hóa" — họ chỉ thấy mình đang làm việc ở mức thách thức phù hợp với bản thân.
________________________________________
3.11. Lựa chọn thời điểm và mức độ sử dụng AI chatbot
Bản chất của quyết định này: Câu hỏi không phải là "có nên cho học sinh dùng AI không" mà là "ở bước nào trong quy trình GQVĐ, dùng AI theo cách nào, sẽ tăng giá trị học tập thay vì giảm đi?" Quyết định này phải xuất phát từ phân tích mục tiêu học tập (mục 3.1) — nếu mục tiêu là học sinh phát triển kỹ năng lập kế hoạch, thì AI không được tham gia vào Bước 4; nếu mục tiêu là học sinh biết sử dụng AI như một công cụ debug, thì AI có thể tham gia nhiều hơn ở Bước 5–6.
Khung quyết định AI-affordance theo quy trình 8 bước:
Bước GQVĐ Vai trò AI phù hợp Mức độ Rủi ro nếu lạm dụng
1. Đọc đề Giải thích thuật ngữ khó, dịch mô tả phức tạp Thấp — chỉ khi HS thực sự không hiểu từ Không đọc kỹ đề, ỷ lại AI tóm tắt
2. Phân tích Đặt câu hỏi phân tích (HS hỏi AI để kiểm chứng phân tích của mình) Trung bình — sau khi HS đã tự phân tích AI phân tích thay HS, HS mất bước tư duy quan trọng nhất
3. Mô hình hóa Kiểm chứng lựa chọn cấu trúc dữ liệu Thấp AI chọn cấu trúc dữ liệu thay HS
4. Lập kế hoạch Không nên — đây là bước mục tiêu cốt lõi nhất Rất thấp/Không HS nhận thuật toán có sẵn, không phát triển được tư duy thiết kế
5. Thực hiện Giải thích lỗi cú pháp (không sửa code thay), giải thích hàm/cú pháp chưa biết Trung bình HS nhận code hoàn chỉnh từ AI, không rèn được kỹ năng cài đặt
6. Kiểm tra Đề xuất thêm test case, giải thích tại sao một test case thất bại Cao — phù hợp AI chạy test và báo kết quả, HS không học cách kiểm thử
7. Đánh giá Gợi ý cải tiến hiệu suất, so sánh với phương án khác Cao — phù hợp AI đánh giá thay HS
8. Khái quát hóa Đề xuất bài toán tương tự để HS thử áp dụng Cao — phù hợp —
Ba kịch bản sử dụng AI có cấu trúc trong lớp học:
Kịch bản 1 — "AI như từ điển thông minh": Học sinh được phép hỏi AI về cú pháp, hàm, khái niệm — nhưng phải tự áp dụng vào bài của mình. GV yêu cầu học sinh "ghi lại câu hỏi đã hỏi AI" vào worksheet — đây vừa là kỹ năng đặt câu hỏi (prompt literacy), vừa là tư liệu chẩn đoán cho GV.
Kịch bản 2 — "AI như reviewer": Sau khi học sinh đã hoàn thành lời giải, AI được phép dùng để review code. GV yêu cầu học sinh: (1) hỏi AI nhận xét về code của mình; (2) đọc nhận xét; (3) tự quyết định chấp nhận hay bác bỏ từng nhận xét và giải thích tại sao. Kỹ năng đánh giá nhận xét của AI là kỹ năng tư duy phê phán quan trọng.
Kịch bản 3 — "AI như đối tác học tập": Học sinh dùng AI để ôn tập — yêu cầu AI đặt câu hỏi về chủ đề vừa học, tự trả lời và nhận phản hồi. Đây là hình thức self-testing hiệu quả trong mô hình B-learning (phần học ở nhà).
Nguyên tắc "Hiểu trước, AI sau": Một nguyên tắc đơn giản nhưng mạnh mẽ — trước khi được phép hỏi AI, học sinh phải thể hiện được rằng mình đã tự suy nghĩ về vấn đề đó. Cách GV kiểm tra: yêu cầu học sinh viết ra "Em đã thử cách này và kết quả là... Em dự đoán nguyên nhân lỗi là... Bây giờ em muốn hỏi AI để kiểm chứng." Quy trình này biến việc dùng AI từ "tìm đáp án" thành "kiểm chứng suy nghĩ" — một sự chuyển dịch nhỏ về hình thức nhưng lớn về chất lượng học tập.
________________________________________
E. TÍCH HỢP AI VÀO CÔNG VIỆC THIẾT KẾ CỦA GIÁO VIÊN
Phần này hướng dẫn sinh viên (với tư cách GV tương lai) sử dụng AI để hỗ trợ 5 công việc thiết kế trong chương này.
Prompt 1 — Xây dựng tình huống có vấn đề:
Tôi cần thiết kế tình huống có vấn đề cho bài dạy lập trình Python
chủ đề [tên chủ đề], đối tượng học sinh lớp [X], trình độ [cơ bản/
trung bình/nâng cao].
Hãy đề xuất 3 tình huống có vấn đề theo 3 dạng khác nhau:
(1) Tình huống thực tế cần tin học hóa — bối cảnh gần gũi với học sinh
THPT Việt Nam.
(2) Tình huống mâu thuẫn nhận thức — điều gì đó bất ngờ, không đúng
với trực giác.
(3) Tình huống sản phẩm có lỗi — cung cấp code/sản phẩm chưa hoàn chỉnh.
Với mỗi tình huống: mô tả bối cảnh, câu hỏi kích hoạt, và chỉ ra tình
huống này đáp ứng 4 tiêu chí (vừa sức, có ý nghĩa, mở vừa phải, kích
thích tư duy) như thế nào.
Prompt 2 — Tạo scaffold nhiều mức:
Bài tập lập trình: [mô tả đề bài].
Đối tượng: học sinh lớp [X] đang học Python.
Điểm khó nhất của bài: [mô tả điểm khó dựa trên phân tích nhiệm vụ].
Hãy tạo 3 mức scaffold cho bài tập này:
- Scaffold mức 1: Code template với nhiều gợi ý, chừa chỗ trống ở phần
tư duy logic.
- Scaffold mức 2: Chỉ có câu hỏi dẫn dắt có cấu trúc (5-7 câu theo
thứ tự), không có code.
- Scaffold mức 3: Chỉ có checklist tự kiểm tra (8-10 mục).
Chú ý: scaffold phải "dỡ dần" — mức 1 hỗ trợ nhiều nhất, mức 3 ít nhất.
Prompt 3 — Sinh câu hỏi gợi mở:
Bài toán: [mô tả bài toán].
Bước GQVĐ cần hỗ trợ: [tên bước, ví dụ: "Bước 3 — Mô hình hóa"].
Lỗi phổ biến học sinh thường gặp ở bước này: [mô tả lỗi].
Hãy tạo 5 câu hỏi gợi mở cho GV sử dụng khi học sinh bị kẹt ở bước
này. Yêu cầu:
- Không hỏi câu hỏi có thể trả lời bằng "Có/Không".
- Không đưa gợi ý về đáp án trong câu hỏi.
- Mỗi câu hỏi dẫn học sinh đến một bước tư duy cụ thể.
- Sắp xếp từ câu hỏi gợi mở nhất đến câu hỏi chỉ dẫn hơn.
Prompt 4 — Thiết kế worksheet:
Tôi cần thiết kế worksheet cho hoạt động GQVĐ sau:
- Chủ đề: [tên chủ đề]
- Bài tập: [mô tả bài toán]
- Thời lượng: [X tiết]
- Trình độ học sinh: [mô tả]
Hãy thiết kế worksheet gồm đủ 7 phần theo cấu trúc GQVĐ 8 bước.
Với mỗi phần: viết tiêu đề, mô tả ngắn mục đích, và 2-3 ô/câu hỏi
cụ thể học sinh cần điền. Phần 6 (Kiểm tra) phải có bảng test case
với ít nhất 4 test case bao gồm edge case.
Prompt 5 — Đề xuất phương án phân hóa:
Hoạt động học tập: [mô tả bài tập và mục tiêu].
Lớp học có 3 nhóm trình độ:
- Nhóm A (25% học sinh): chưa vững kỹ năng cú pháp cơ bản.
- Nhóm B (50% học sinh): nắm cú pháp nhưng chưa tự thiết kế được thuật toán.
- Nhóm C (25% học sinh): có thể tự giải và muốn thách thức thêm.
Hãy đề xuất phương án phân hóa theo 3 chiều:
(1) Phân hóa đầu vào: mức scaffold khác nhau cho mỗi nhóm.
(2) Phân hóa quá trình: hoạt động khác nhau trong tiết học.
(3) Phân hóa đầu ra: tiêu chí đánh giá thành công khác nhau.
Đảm bảo tất cả nhóm đều đạt được mục tiêu cốt lõi của bài tập.
________________________________________
F. THỰC HÀNH (4 tiết) — THIẾT KẾ HOÀN CHỈNH MỘT HOẠT ĐỘNG GQVĐ
Mục tiêu thực hành
Sinh viên hoàn thành một bộ thiết kế hoạt động GQVĐ hoàn chỉnh cho một chủ đề trong chương trình Tin học phổ thông — đủ chi tiết để một GV khác có thể dạy theo mà không cần hỏi thêm.
________________________________________
Mẫu bộ thiết kế hoàn chỉnh — Ví dụ tham chiếu
(Đây là ví dụ mẫu GV cung cấp để sinh viên tham chiếu. Sinh viên tự chọn chủ đề khác.)
Chủ đề: Kiểm tra số nguyên tố — Tin học 10, Kết nối tri thức Thời lượng: 1 tiết thực hành (45 phút) Đối tượng: Học sinh lớp 10, đã học vòng lặp for, while, toán tử %, câu lệnh if-else
________________________________________
PHẦN 1: PHÂN TÍCH MỤC TIÊU
Tầng Nội dung
Kiến thức Tiên quyết: vòng lặp for, if-else, toán tử %; Mục tiêu: break, biến flag, range với √n
Kỹ năng (1) Dịch định nghĩa toán học sang điều kiện lập trình; (2) Dùng break thoát vòng lặp sớm; (3) Quản lý biến flag; (4) Xử lý trường hợp đặc biệt (n<2); (5) Thiết kế test case bao phủ
Năng lực NLc (thiết kế thuật toán), NLa (dùng Python IDLE)
Mục tiêu sàn Viết được code kiểm tra số nguyên tố với range(2, n)
Mục tiêu trần Tối ưu với range(2, int(n**0.5)+1) và giải thích được tại sao
Mục tiêu hỗ trợ Điền đúng điều kiện vào code template để chương trình chạy đúng
________________________________________
PHẦN 2: PHÂN TÍCH NHIỆM VỤ
Nhiệm vụ đầu cuối: Viết chương trình Python nhập n, in "Nguyên tố"
hoặc "Không nguyên tố"
MT1 [Tiên quyết]: Biết định nghĩa số nguyên tố
MT2: Xử lý trường hợp n < 2 → Không nguyên tố [cần dạy]
MT3: Viết vòng lặp kiểm tra ước từ 2 đến n-1 [cần dạy]
MT3a: Hiểu tại sao chỉ cần đến √n [ĐIỂM KHÓ]
MT4: Dùng break khi tìm thấy ước [ĐIỂM KHÓ]
MT5: Dùng biến flag / else của for [ĐIỂM KHÓ]
MT6: In kết quả đúng dựa trên kết quả vòng lặp
MT7: Kiểm thử với 5+ test case bao phủ edge case
ĐIỂM KHÓ cần scaffold: MT3a, MT4, MT5
________________________________________
PHẦN 3: TÌNH HUỐNG CÓ VẤN ĐỀ
Dạng sử dụng: Tình huống mâu thuẫn nhận thức + Tình huống sản phẩm có lỗi
Bối cảnh: GV chiếu lên màn hình một đoạn hội thoại:
"Hôm qua em viết chương trình kiểm tra số nguyên tố. Em chạy thử với số 7 thì được kết quả đúng. Nhưng khi thầy giáo thử với số 1, chương trình lại nói 1 là số nguyên tố. Em không hiểu tại sao."
Sau đó GV chiếu code của "bạn học sinh" đó (code thiếu điều kiện xử lý n<2 và có lỗi ở điều kiện flag).
Câu hỏi kích hoạt: "Theo em, code này sai ở đâu? Nếu em là tác giả code này, em sẽ kiểm tra lại như thế nào để tìm ra lỗi?"
Thời gian: 5 phút — học sinh thảo luận cặp đôi, sau đó 2–3 cặp chia sẻ phát hiện của mình. GV chưa chốt đúng sai, chỉ ghi nhận các ý kiến lên bảng.
________________________________________
PHẦN 4: HỆ THỐNG BÀI TẬP BA TẦNG
Tầng 1 — Củng cố (Bắt buộc):
Viết chương trình Python nhập số nguyên dương n từ bàn phím, kiểm tra và in ra "n là số nguyên tố" hoặc "n không phải số nguyên tố". Chương trình phải xử lý đúng với n=0, n=1, n=2.
Tầng 2 — Kết hợp (Khuyến khích):
Mở rộng chương trình trên: sau khi kiểm tra, nếu n không phải số nguyên tố, in ra ước số nhỏ nhất của n (lớn hơn 1). Ví dụ: n=12 → "12 không phải số nguyên tố, ước nhỏ nhất là 2"; n=15 → "15 không phải số nguyên tố, ước nhỏ nhất là 3".
Tầng 3 — Nâng cao (Tự chọn):
Trong code của "bạn học sinh" ở phần tình huống, có hai lỗi. Hãy: (a) Xác định chính xác hai lỗi đó là gì (lỗi cú pháp/khái niệm/logic?). (b) Sửa lại cho đúng. (c) Viết lại code với tối ưu hóa: chỉ kiểm tra ước đến √n. (d) Đo thời gian chạy với n=999983 (số nguyên tố lớn) của hai phiên bản và so sánh.
________________________________________
PHẦN 5: HỆ THỐNG SCAFFOLD
Scaffold A — Code template mức 1 (dành cho Nhóm A):
def kiem_tra_nguyen_to(n):
# Bước 1: Xử lý trường hợp đặc biệt
if n < 2:
return _______ # Điền True hoặc False
# Bước 2: Kiểm tra ước từ 2 đến n-1
for i in range(_______, _______): # Điền phạm vi
if n % i == 0: # Nếu tìm thấy ước
return False
# Bước 3: Nếu không tìm thấy ước nào → số nguyên tố
return _______ # Điền True hoặc False
# Phần chính
n = int(input("Nhập số nguyên n: "))
if kiem_tra_nguyen_to(n):
print(n, "là số nguyên tố")
else:
print(n, "không phải số nguyên tố")
Scaffold B — Câu hỏi dẫn dắt (dành cho Nhóm B):
1. Số nguyên tố được định nghĩa là số lớn hơn 1, chỉ có 2 ước là 1 và chính nó. Vậy những số nào chắc chắn KHÔNG phải số nguyên tố mà em cần xử lý ngay từ đầu?
2. Để kiểm tra n có ước nào từ 2 đến n-1 không, em cần duyệt qua những số nào? Viết range(...) phù hợp.
3. Ngay khi tìm thấy một số i chia hết cho n (tức n % i == 0), em cần tiếp tục kiểm tra các số tiếp theo nữa không? Tại sao? Lệnh nào trong Python giúp em thoát khỏi vòng lặp ngay lập tức?
4. Sau khi vòng lặp kết thúc, làm thế nào em biết vòng lặp kết thúc vì "đã tìm thấy ước" hay vì "đã kiểm tra hết mà không tìm thấy ước nào"?
5. Viết thử giả mã (ngôn ngữ tự nhiên) cho thuật toán của em trước khi viết code Python.
Scaffold C — Checklist (dành cho Nhóm C và tất cả khi nộp bài):
• [ ] Code chạy không báo lỗi cú pháp.
• [ ] n=2 → in "2 là số nguyên tố" (số nguyên tố nhỏ nhất).
• [ ] n=1 → in "1 không phải số nguyên tố".
• [ ] n=0 → xử lý đúng.
• [ ] n=-5 → xử lý đúng.
• [ ] n=17 → in "17 là số nguyên tố".
• [ ] n=15 → in "15 không phải số nguyên tố".
• [ ] Biến và hàm có tên rõ nghĩa.
• [ ] Có comment giải thích logic của vòng lặp.
________________________________________
PHẦN 6: WORKSHEET
(Xem mẫu worksheet hoàn chỉnh — phát cho từng học sinh)
________________________________________
PHIẾU HỌC TẬP — BÀI TOÁN KIỂM TRA SỐ NGUYÊN TỐ Họ tên: ...................... Lớp: ......... Ngày: .........
PHẦN 1 — ĐỌC ĐỀ VÀ PHÂN TÍCH (5 phút)
Đề bài: Viết chương trình nhập số nguyên n, kiểm tra và in ra n có phải số nguyên tố không.
Câu hỏi phân tích Câu trả lời của em
Input là gì? Kiểu dữ liệu?
Output cần in ra là gì? (ghi chính xác)
Trường hợp đặc biệt nào cần xử lý riêng?
Em chưa rõ điều gì trong đề bài?
PHẦN 2 — MÔ HÌNH HÓA (5 phút)
Mô tả thuật toán bằng ngôn ngữ tự nhiên (không viết code):
Bước 1: ............................................................................
Bước 2: ............................................................................
Bước 3: ............................................................................
Bước 4: ............................................................................
PHẦN 3 — LẬP KẾ HOẠCH (5 phút)
Viết giả mã hoặc sơ đồ khối cho thuật toán của em:
(Không gian trống để vẽ/viết)
PHẦN 4 — THỰC HIỆN
Viết code Python vào máy tính. Khi hoàn thành, ghi địa chỉ file: .......................
PHẦN 5 — KIỂM TRA (Bắt buộc trước khi nộp)
Input Output mong đợi Output thực tế của em Đúng?
n = 2 2 là số nguyên tố
n = 1 1 không phải số nguyên tố
n = 0 0 không phải số nguyên tố
n = -5 -5 không phải số nguyên tố
n = 17 17 là số nguyên tố
n = 15 15 không phải số nguyên tố
n = 97 97 là số nguyên tố
(Test case em tự thêm)
PHẦN 6 — ĐÁNH GIÁ VÀ KHÁI QUÁT HÓA (5 phút)
1. Em gặp khó khăn nhất ở bước nào? Tại sao?
.............................................................................................
2. Điều gì trong bài này sẽ dùng được khi giải các bài toán khác?
.............................................................................................
3. Nếu n rất lớn (ví dụ n = 999999937), chương trình của em còn chạy nhanh không? Em nghĩ có cách nào cải thiện?
.............................................................................................
4. Em đã sử dụng AI trong bài này không? Nếu có, em đã hỏi gì và nhận xét gì về câu trả lời của AI?
.............................................................................................
________________________________________
PHẦN 7: HỆ THỐNG CÂU HỎI GỢI MỞ CHO GV
(GV dùng khi học sinh bị kẹt — không đọc to toàn bộ danh sách này, chỉ dùng câu phù hợp với bước học sinh đang gặp khó)
Khi học sinh không biết bắt đầu (Bước 1–2):
• "Em hãy đọc lại đề, gạch chân những từ khóa quan trọng nhất."
• "Input của bài này là gì? Output là gì? Viết ra giấy đi."
• "Số nguyên tố được định nghĩa như thế nào? Em có nhớ từ môn Toán không?"
Khi học sinh không biết cấu trúc vòng lặp (Bước 3–4):
• "Em cần kiểm tra những số nào để xem n có ước hay không?"
• "Em muốn duyệt qua một dãy số — lệnh Python nào làm được điều đó?"
• "Hãy viết giả mã bằng tiếng Việt trước: 'Với mỗi số i từ... đến..., nếu... thì...'"
Khi học sinh chưa biết dùng break (Bước 5):
• "Ngay khi em tìm thấy một số i mà n chia hết cho i, em còn cần kiểm tra các số tiếp theo không? Tại sao không?"
• "Lệnh nào trong Python cho phép em thoát khỏi vòng lặp ngay lập tức?"
Khi học sinh không biết kiểm tra kết quả vòng lặp (Bước 5):
• "Sau khi vòng lặp kết thúc, làm thế nào em biết nó kết thúc vì sao?"
• "Python có cú pháp for...else — em thử tìm hiểu xem else của for có nghĩa gì?"
Khi học sinh không kiểm thử đủ test case (Bước 6):
• "Em đã thử với n=1 chưa? Chương trình làm gì?"
• "Số âm thì sao? Em muốn chương trình xử lý thế nào?"
• "Hãy nghĩ xem có trường hợp nào 'đặc biệt' chương trình có thể bị sai không?"
________________________________________
PHẦN 8: TIẾN TRÌNH TỔ CHỨC TIẾT HỌC (45 phút)
Giai đoạn Thời gian Hoạt động GV Hoạt động HS Scaffold sử dụng
Khởi động — THCVĐ 5 phút Chiếu code lỗi của "bạn học sinh"; đặt câu hỏi kích hoạt Thảo luận cặp đôi, chia sẻ phát hiện —
Phân tích + Mô hình hóa 8 phút Phát worksheet; quan sát; đặt câu hỏi gợi mở Tầng 1 Hoàn thành Phần 1–3 của worksheet Câu hỏi định hướng
Lập kế hoạch 5 phút Yêu cầu HS viết giả mã trước khi code; không được bỏ qua Viết giả mã vào Phần 3 worksheet; GV kiểm tra milestone Câu hỏi khám phá
Thực hành 18 phút Di chuyển; hỗ trợ theo mức (gợi mở → chỉ dẫn → mẫu); phát scaffold phù hợp từng nhóm Viết code; chạy thử; điền bảng test case Scaffold A/B/C tùy nhóm
Kiểm tra + Đánh giá 5 phút Chiếu code đúng và code có lỗi; yêu cầu HS so sánh Hoàn thành Phần 5–6 worksheet; điền bảng test case Checklist
Tổng kết 4 phút Chốt 3 điểm quan trọng; giới thiệu Bài tập Tầng 3 cho HS nhanh Ghi chú bài học rút ra —
________________________________________
PHẦN 9: RUBRIC ĐÁNH GIÁ SẢN PHẨM
Tiêu chí Xuất sắc (4) Đạt (3) Cần cải thiện (2) Chưa đạt (1)
Tính đúng đắn Đúng tất cả 7 test case kể cả edge case Đúng 5–6/7 test case Đúng 3–4/7 Đúng ≤2/7
Chất lượng thuật toán Có giả mã trước code; logic rõ ràng; xử lý đủ trường hợp Có giả mã; logic đúng nhưng thiếu 1 trường hợp Không có giả mã; logic có sai sót Code ngẫu nhiên, không có cấu trúc
Kiểm thử Tự thiết kế thêm test case ngoài yêu cầu Điền đủ bảng test case theo yêu cầu Điền thiếu bảng test case Không kiểm thử
Phản tư Phần 6 worksheet trả lời sâu, cụ thể, có ví dụ Phần 6 trả lời đủ nhưng chung chung Phần 6 trả lời sơ sài Bỏ trống Phần 6
________________________________________
Yêu cầu sản phẩm thực hành của sinh viên
Mỗi nhóm 2–3 sinh viên chọn một chủ đề trong chương trình Tin học phổ thông (khác với ví dụ mẫu, phải phủ ít nhất 2/8 nhóm bài tập theo Chương 2) và hoàn thành bộ thiết kế gồm đủ 9 phần như ví dụ mẫu trên. Bộ thiết kế được trình bày và bảo vệ trước lớp, các nhóm khác đóng vai học sinh và thực tế làm thử hoạt động trong 15 phút.
________________________________________
G. RUBRIC ĐÁNH GIÁ BỘ THIẾT KẾ HOẠT ĐỘNG GQVĐ CỦA SINH VIÊN
Thành phần Tốt (3đ) Đạt (2đ) Chưa đạt (1đ)
Phân tích mục tiêu (3.1) Đủ 3 tầng; mục tiêu sàn/trần/hỗ trợ rõ; nhất quán với CT GDPT 2018 Đủ 3 tầng nhưng mục tiêu còn chung chung Thiếu tầng hoặc mục tiêu không đánh giá được
Phân tích nhiệm vụ (3.2) Sơ đồ phân rã đủ sâu; xác định được điểm khó; quan hệ phụ thuộc rõ Phân rã ở mức trung bình; thiếu xác định điểm khó Chỉ liệt kê, không có sơ đồ phụ thuộc
Tình huống có vấn đề (3.3) Đáp ứng đủ 4 tiêu chí; bối cảnh phù hợp học sinh; câu hỏi kích hoạt mở Có bối cảnh nhưng thiếu 1–2 tiêu chí THCVĐ là bài tập thông thường, không tạo ra khoảng cách nhận thức
Hệ thống bài tập (3.4) 3 tầng rõ; Tầng 3 đòi hỏi tư duy Bloom 4–5; bài tập mẹ–con nhất quán 3 tầng nhưng độ khó chênh lệch không đủ lớn Chỉ có 1–2 mức; thiếu bài tập nâng cao
Câu hỏi gợi mở (3.5) 3 tầng câu hỏi; phủ đủ 8 bước GQVĐ; không đưa gợi ý đáp án Có câu hỏi nhưng một số câu trả lời được bằng Có/Không Câu hỏi chủ yếu là câu hỏi kiến thức, không phải gợi mở
Scaffold (3.6) 3 mức rõ; có lộ trình dỡ dần; scaffold tập trung đúng điểm khó 2 mức scaffold; chưa có lộ trình dỡ dần Chỉ có 1 mức; scaffold quá nhiều hoặc quá ít
Worksheet (3.7) Đủ 7 phần; bảng test case có edge case; phần phản tư có giá trị Đủ 7 phần nhưng phần phản tư sơ sài Thiếu phần mô hình hóa hoặc kiểm tra
Phân hóa (3.10) 3 chiều phân hóa rõ; không gây cô lập học sinh yếu 2 chiều phân hóa; nhóm yếu còn bị cô lập Chỉ phân hóa theo tầng bài tập
Tích hợp AI (3.11) Chính sách AI rõ theo từng bước GQVĐ; có lý do sư phạm Có chính sách AI nhưng chưa gắn với bước GQVĐ cụ thể Không có chính sách AI hoặc cấm hoàn toàn
Tính nhất quán tổng thể Tất cả 9 phần nhất quán với nhau; có thể dạy ngay không cần điều chỉnh Nhất quán ở phần lớn; một vài điểm chưa khớp Mâu thuẫn rõ giữa các phần
Tổng: 30 điểm → Quy về 10
________________________________________
H. TÀI LIỆU THAM KHẢO
• Bộ GD&ĐT (2018). Chương trình giáo dục phổ thông môn Tin học (Thông tư 32/2018/TT-BGDĐT).
• Polya, G. (1945). How to Solve It. Princeton University Press.
• Bransford, J. D., & Stein, B. S. (1984). The IDEAL Problem Solver. Freeman.
• Vygotsky, L. S. (1978). Mind in Society: The Development of Higher Psychological Processes. Harvard University Press. (Nguồn gốc khái niệm ZPD và scaffold)
• Wood, D., Bruner, J. S., & Ross, G. (1976). The role of tutoring in problem solving. Journal of Child Psychology and Psychiatry, 17(2), 89–100. (Nguồn gốc khái niệm scaffolding)
• Rowe, M. B. (1986). Wait time: Slowing down may be a way of speeding up! Journal of Teacher Education, 37(1), 43–50.
• Tomlinson, C. A. (2001). How to Differentiate Instruction in Mixed-Ability Classrooms (2nd ed.). ASCD.
• Williams, L. (2001). Integrating pair programming into a software development process. Proceedings of the 14th Conference on Software Engineering Education and Training.
• Hoàng Lê Minh (Tổng chủ biên) (2023). Tin học 10 — Kết nối tri thức với cuộc sống. NXB Giáo dục Việt Nam.
• UNESCO (2023). Guidance for generative AI in education and research.
CHƯƠNG 4: TỔ CHỨC VÀ HỖ TRỢ HỌC SINH GIẢI QUYẾT VẤN ĐỀ
Thời lượng: 6 tiết (3 tiết lý thuyết + 3 tiết thực hành)
________________________________________
A. VỊ TRÍ CHƯƠNG TRONG HỌC PHẦN
Chương 3 trang bị cho sinh viên kỹ năng thiết kế — tạo ra tình huống, bài tập, scaffold, worksheet trên giấy. Chương 4 chuyển sang thực thi — khi học sinh thực sự ngồi trước máy tính và bắt đầu giải quyết vấn đề, GV phải làm gì? Đây là khoảng cách lớn nhất và khó nhất trong nghề dạy học: thiết kế tốt trên giấy không tự động dẫn đến giờ học tốt trên lớp. Chương 4 lấp đầy khoảng cách đó.
Logic của chương: GV cần nhìn thấy học sinh đang ở đâu (phát hiện khó khăn) → quyết định can thiệp như thế nào (lựa chọn kỹ thuật) → thực hiện can thiệp đúng thời điểm → tổ chức môi trường lớp học để can thiệp hiệu quả. Bốn bước này không tuyến tính mà diễn ra liên tục, đồng thời, trong suốt giờ học.
________________________________________
B. MỤC TIÊU CHƯƠNG
Sau chương này, sinh viên có thể:
• Nhận diện được các dấu hiệu học sinh đang gặp khó khăn tại từng bước trong quy trình GQVĐ 8 bước.
• Lựa chọn và thực hiện được kỹ thuật hỗ trợ phù hợp (scaffold, debugging, questioning, pair programming, peer learning, tranh luận, phản biện) theo từng tình huống cụ thể.
• Tổ chức được các hình thức học tập (cá nhân, cặp đôi, nhóm, PBL, PjBL) phù hợp với từng loại nhiệm vụ GQVĐ.
• Vận dụng được ít nhất 4 kỹ thuật dạy học đặc thù (Think–Pair–Share, Debug Together, Peer Review, Gallery Walk) trong tổ chức giờ GQVĐ.
• Tích hợp AI như một đối tác học tập có kiểm soát: hướng dẫn học sinh dùng AI debug, đánh giá lời giải AI và phản biện code AI sinh ra.
• Xử lý được các tình huống sư phạm điển hình trong giờ GQVĐ Tin học thông qua mô phỏng lớp học.
________________________________________
C. NỘI DUNG LÝ THUYẾT (3 tiết)
________________________________________
4.1. Phát hiện khó khăn của học sinh
Bản chất và tầm quan trọng: Phát hiện khó khăn là kỹ năng quan sát sư phạm — khả năng GV "đọc được" trạng thái nhận thức của học sinh qua các dấu hiệu hành vi có thể quan sát được, ngay cả khi học sinh không chủ động báo hiệu. Đây là kỹ năng tiên quyết của toàn bộ chương — nếu GV không phát hiện được học sinh đang bị kẹt ở đâu, mọi kỹ thuật hỗ trợ phía sau đều trở nên vô nghĩa hoặc sai thời điểm.
Thực tế trong phòng máy Tin học: đa số học sinh không chủ động giơ tay khi gặp khó. Nguyên nhân phổ biến gồm: sợ bị bạn bè đánh giá, không biết mình đang gặp khó ở đâu (metacognitive gap), tin rằng GV đang bận với học sinh khác, hoặc đơn giản là cảm thấy xấu hổ khi không làm được. GV chờ học sinh giơ tay sẽ bỏ sót phần lớn những em cần hỗ trợ nhất.
Hệ thống tín hiệu nhận diện khó khăn — phân loại theo loại khó khăn:
Nhóm 1 — Tín hiệu hành vi quan sát được:
Hành vi quan sát Loại khó khăn có thể Bước GQVĐ đang gặp vấn đề
Ngồi im, không gõ phím > 3 phút Không biết bắt đầu từ đâu Bước 1–2 (Đọc đề, Phân tích)
Liên tục xóa và gõ lại cùng một đoạn code Lỗi cú pháp lặp lại, không hiểu nguyên nhân Bước 5 (Thực hiện)
Gõ rất nhiều, màn hình đầy code nhưng không chạy thử Bỏ qua bước kiểm tra, viết theo quán tính Bước 6 (Kiểm tra)
Nhìn sang màn hình bạn bên cạnh liên tục Không có hướng giải hoặc không hiểu đề Bước 3–4 (Mô hình hóa, Lập kế hoạch)
Nộp bài rất nhanh (< 5 phút với bài 20 phút) Làm theo template mà không hiểu, hoặc bài quá dễ Cần kiểm tra thực chất
Vẻ mặt bối rối, nhìn đề bài nhiều lần Không hiểu đề Bước 1 (Đọc đề)
Chương trình chạy nhưng học sinh vẫn nhìn chằm chằm vào màn hình Kết quả sai nhưng không biết tại sao Bước 6–7 (Kiểm tra, Đánh giá)
Hỏi bạn liên tục, bạn giải thích nhưng gật đầu mà không làm được Khó khăn về kiến thức nền, không phải về bài tập hiện tại Kiến thức tiên quyết thiếu
Nhóm 2 — Tín hiệu qua sản phẩm trung gian:
Khi GV đi qua và nhìn nhanh màn hình học sinh (10–15 giây mỗi máy), có thể nhận diện:
• Code trống hoặc chỉ có tiêu đề → chưa bắt đầu được (Bước 1–2).
• Code có cấu trúc đúng nhưng sai logic → lỗi thuật toán (Bước 4).
• Code chạy cho ra kết quả nhưng sai với test case đặc biệt → chưa kiểm thử đủ (Bước 6).
• Thông báo lỗi đỏ trên màn hình mà học sinh không xử lý → không biết đọc error message (kỹ năng debugging thiếu).
• Worksheet còn trống phần mô hình hóa → bỏ qua Bước 3 để nhảy thẳng vào code.
Nhóm 3 — Tín hiệu qua câu hỏi học sinh đặt ra:
Câu hỏi học sinh đặt ra tiết lộ chính xác bước họ đang gặp khó:
• "Em không hiểu đề muốn gì" → Bước 1.
• "Em không biết dùng cấu trúc dữ liệu gì" → Bước 3.
• "Em không biết bắt đầu viết code từ đâu" → Bước 4.
• "Em bị lỗi SyntaxError nhưng không biết ở đâu" → Bước 5.
• "Code em chạy đúng rồi nhưng không biết có đúng thật không" → Bước 6.
• "Em làm xong rồi thầy ơi, làm tiếp gì không?" → Bước 7–8 (cần bài Tầng 2–3).
Kỹ thuật quan sát chủ động — "Lộ trình di chuyển có chủ đích":
GV không đứng yên một chỗ và không di chuyển ngẫu nhiên. Lộ trình di chuyển cần được thiết kế:
• Vòng đầu (5 phút đầu giờ thực hành): Đi nhanh qua tất cả máy, chỉ nhìn màn hình, không dừng lại. Mục tiêu: phân loại nhanh — nhóm nào đã bắt đầu được, nhóm nào chưa.
• Vòng hai (10–15 phút tiếp theo): Tập trung vào nhóm chưa bắt đầu hoặc đang bị kẹt. Dừng lâu hơn, đặt câu hỏi gợi mở.
• Vòng ba (10 phút cuối): Kiểm tra bảng test case của học sinh đã hoàn thành, đặt câu hỏi đánh giá và khái quát hóa (Bước 7–8).
Nguyên tắc vàng: GV luôn đứng ở vị trí có thể nhìn thấy toàn bộ màn hình lớp — đứng sau lưng học sinh, nhìn từ phía sau, không đứng trước màn hình học sinh (vừa che tầm nhìn của học sinh vừa mất đi khả năng quan sát toàn lớp).
________________________________________
4.2. Các kỹ thuật hỗ trợ trong giờ GQVĐ
4.2.1. Scaffold theo tình huống thực
Scaffold đã được giới thiệu ở góc độ thiết kế trong Chương 3 (mục 3.6). Ở đây, trọng tâm là scaffold trong thực thi — khi GV quan sát học sinh đang bị kẹt và quyết định cung cấp loại hỗ trợ nào, theo cách nào, ở mức độ nào.
Nguyên tắc "scaffold tối thiểu cần thiết" (minimal scaffolding principle): GV luôn bắt đầu với mức hỗ trợ ít nhất đủ để học sinh tiến thêm được một bước — không nhiều hơn. Mục tiêu không phải là giúp học sinh giải xong bài, mà là giúp học sinh tự giải xong bài. Đây là ranh giới tinh tế nhưng quyết định toàn bộ chất lượng học tập.
Ba mức scaffold thực thi (từ ít đến nhiều hỗ trợ):
Mức 1 — Metacognitive scaffold (Hỗ trợ nhận thức về tiến trình): GV không cung cấp thông tin về bài toán mà giúp học sinh nhận ra họ đang ở đâu trong quy trình và cần làm gì tiếp theo.
Câu mẫu: "Em đang ở bước nào trong quy trình 8 bước? Em đã hoàn thành bước trước chưa?" — Câu hỏi này không giúp giải bài nhưng giúp học sinh định hướng lại khi bị lạc.
Mức 2 — Conceptual scaffold (Hỗ trợ khái niệm): GV cung cấp một gợi ý khái niệm mà không tiết lộ cách áp dụng vào bài toán cụ thể.
Câu mẫu: "Em có nhớ trong Python, khi muốn thoát khỏi vòng lặp trước khi điều kiện kết thúc, có lệnh gì không?" — Học sinh tự kết nối lệnh break với bài toán của mình.
Mức 3 — Procedural scaffold (Hỗ trợ thủ tục): GV hướng dẫn học sinh thực hiện một bước cụ thể — nhưng không làm thay. GV chỉ vào màn hình, chỉ dẫn bằng ngón tay, đặt câu hỏi từng micro-bước.
Câu mẫu: "Dòng này em muốn làm gì? Cú pháp của lệnh đó là gì? Thử viết thử xem." — GV không gõ vào máy của học sinh.
Quy tắc "Tay không chạm bàn phím": Trong suốt giờ thực hành, tay GV không đặt lên bàn phím hoặc chuột của học sinh, trừ khi cần demo cú pháp hoàn toàn mới (và ngay cả khi đó, GV gõ mẫu trên máy chiếu hoặc máy riêng, không gõ trên máy học sinh). Quy tắc này đảm bảo học sinh tự thao tác — phát triển kỹ năng thực hành đòi hỏi tự tay làm, không phải xem GV làm.
4.2.2. Debugging hỗ trợ (Supported Debugging)
Bản chất: Debugging (gỡ lỗi) là kỹ năng tư duy đặc thù của lập trình — không phải chỉ là sửa code mà là phát hiện và hiểu nguyên nhân của lỗi. GV hỗ trợ debugging không có nghĩa là sửa lỗi cho học sinh — mà là dạy học sinh cách tư duy khi gặp lỗi.
Quy trình debugging có hỗ trợ — 5 bước:
Bước 1 — Đọc thông báo lỗi: Phần lớn học sinh phản xạ với thông báo lỗi là hoảng sợ và gọi GV ngay — không thèm đọc. GV cần rèn phản xạ: đọc trước, gọi sau. Câu mẫu: "Em đọc thông báo lỗi cho thầy/cô nghe — đọc to lên." Hành động đọc to buộc học sinh thực sự đọc, không chỉ nhìn.
Bước 2 — Xác định loại lỗi: GV giúp học sinh phân loại: SyntaxError (sai cú pháp — dễ sửa), NameError (biến chưa khai báo), TypeError (sai kiểu dữ liệu), IndexError (sai chỉ số), hay LogicError (code chạy nhưng kết quả sai — khó nhất). Câu mẫu: "Lỗi này thuộc loại nào? Loại lỗi này thường xảy ra khi...?"
Bước 3 — Xác định vị trí lỗi: Python thông báo số dòng lỗi — nhưng lỗi thực sự đôi khi ở dòng trước đó. Câu mẫu: "Python nói lỗi ở dòng số mấy? Hãy nhìn vào dòng đó và dòng ngay trước nó."
Bước 4 — Giả thuyết nguyên nhân: Học sinh đề xuất lý do tại sao lỗi xảy ra. Câu mẫu: "Em nghĩ tại sao lại có lỗi này? Dòng này em muốn làm gì nhưng máy hiểu là gì?"
Bước 5 — Sửa và kiểm tra: Học sinh sửa và chạy lại. Quan trọng: sau khi sửa xong, GV đặt câu hỏi: "Tại sao cách sửa này đúng?" — đảm bảo học sinh hiểu, không chỉ sửa may mắn.
Kỹ thuật "Chạy tay" (Tracing/Dry run): Khi lỗi logic khó phát hiện, GV hướng dẫn học sinh "chạy tay" — thực hiện từng bước thuật toán bằng tay trên giấy, với một bộ dữ liệu nhỏ cụ thể. Đây là kỹ thuật debugging cổ điển nhưng cực kỳ hiệu quả, đặc biệt với học sinh mới học lập trình.
Ví dụ (bài tìm max trong mảng): GV đưa cho học sinh tờ giấy: "Em hãy chạy tay thuật toán này với mảng [3, 7, 2, 9, 1]. Ở mỗi bước lặp, ghi ra giá trị của biến max_val và biến i. Giờ so sánh với kết quả máy in ra — có khớp không?"
Debug Together — Kỹ thuật nhóm: Thay vì GV sửa lỗi cho học sinh, tổ chức cả lớp hoặc nhóm nhỏ cùng debug một lỗi điển hình được chiếu lên màn hình (ẩn tên chủ nhân). GV đóng vai "người dẫn chương trình", đặt câu hỏi để lớp cùng phân tích. Hình thức này có giá trị kép: học sinh học cách tư duy debugging từ nhau, và học sinh có code được debug cảm thấy được hỗ trợ tập thể thay vì bị sửa lỗi một mình.
4.2.3. Questioning — Nghệ thuật đặt câu hỏi trong giờ GQVĐ
Bản chất: Questioning không chỉ là đặt câu hỏi — mà là sử dụng câu hỏi như công cụ can thiệp sư phạm chính xác, thay thế cho giải thích trực tiếp. Mỗi câu hỏi GV đặt ra cần có mục tiêu rõ ràng: dẫn học sinh đến bước tư duy tiếp theo, không phải dẫn đến đáp án.
Bốn loại câu hỏi GV cần thành thạo trong giờ GQVĐ:
Câu hỏi làm rõ (Clarifying questions): Mục tiêu: giúp học sinh nói rõ hơn những gì họ đang nghĩ — không phải để GV hiểu, mà để học sinh tự nghe lại mình và nhận ra mâu thuẫn hoặc thiếu sót. Ví dụ: "Em vừa nói 'biến này lưu điểm học sinh' — điểm của học sinh nào? Tất cả hay từng người? Kiểu dữ liệu là gì?"
Câu hỏi thăm dò (Probing questions): Mục tiêu: đi sâu hơn vào lý luận của học sinh, kiểm tra xem học sinh hiểu thực sự hay chỉ nhớ máy móc. Ví dụ: "Tại sao em dùng while ở đây mà không dùng for?" — Nếu học sinh không trả lời được, đó là dấu hiệu học sinh chọn cấu trúc theo quán tính, không phải theo hiểu biết.
Câu hỏi mở rộng (Extending questions): Mục tiêu: kéo học sinh ra khỏi bài toán hiện tại để kết nối với kiến thức rộng hơn — dùng cho học sinh đã hoàn thành. Ví dụ: "Thuật toán của em hoạt động tốt. Nếu dữ liệu đầu vào có thể có lỗi (người dùng nhập chữ thay vì số), em xử lý thế nào?"
Câu hỏi chuyển hướng (Redirecting questions): Mục tiêu: nhẹ nhàng đưa học sinh đang đi sai hướng về đúng hướng mà không nói thẳng "em sai rồi". Ví dụ: "Hướng em đang làm thú vị đấy. Thử chạy với test case [-1, 0, 0] xem kết quả thế nào — có đúng với yêu cầu đề bài không?"
Kỹ thuật Socratic Questioning trong debugging:
Khi học sinh có lỗi logic, thay vì chỉ ra lỗi, GV dẫn học sinh tự phát hiện qua chuỗi câu hỏi:
1. "Chương trình của em đang làm gì?" (học sinh mô tả)
2. "Em muốn chương trình làm gì?" (học sinh nêu mục tiêu)
3. "Sự khác biệt giữa điều đang xảy ra và điều em muốn là gì?" (học sinh tự xác định lỗi)
4. "Dòng nào trong code có thể gây ra sự khác biệt đó?" (học sinh xác định vị trí)
5. "Thử sửa dòng đó và chạy lại — kết quả thế nào?" (học sinh tự sửa và kiểm chứng)
Chuỗi này có thể mất 5–7 phút thay vì 30 giây nếu GV chỉ thẳng vào lỗi — nhưng giá trị học tập cao hơn gấp nhiều lần.
4.2.4. Pair Programming trong lớp học
Bản chất và lợi ích: Pair Programming (lập trình đôi) là kỹ thuật học sinh làm việc theo cặp trên một máy tính, chia hai vai: Driver (người lái — gõ code, tập trung vào cú pháp từng dòng) và Navigator (người dẫn đường — quan sát toàn bộ, phát hiện lỗi logic, gợi ý bước tiếp theo, giữ bức tranh tổng thể). Hai vai luân phiên mỗi 10–15 phút.
Lợi ích đã được nghiên cứu xác nhận (Williams & Kessler, 2002): code ít lỗi hơn 15% so với làm cá nhân, học sinh yếu được hỗ trợ tự nhiên từ bạn Navigator, học sinh giỏi củng cố hiểu biết qua việc giải thích, cả hai đều phát triển kỹ năng giao tiếp kỹ thuật.
Quy tắc Pair Programming trong lớp học:
Quy tắc Lý do sư phạm
Navigator không được chỉ tay vào bàn phím Ngăn Navigator "làm thay" Driver
Navigator được phép chỉ vào màn hình và đặt câu hỏi Khuyến khích thảo luận, không độc thoại
Driver giải thích to những gì đang gõ Buộc Driver tư duy thay vì gõ theo quán tính
Luân phiên vai đúng giờ, không trì hoãn Đảm bảo cả hai đều được rèn luyện cả hai vai
Không được có hai bàn phím cùng lúc Ngăn cả hai cùng gõ — mất đi vai trò
GV hỗ trợ cặp Pair Programming như thế nào: GV không can thiệp vào cặp đang hoạt động tốt. GV chỉ tiếp cận khi: cặp đang tranh luận quá lâu mà không ra quyết định (> 3 phút) — GV hỏi "Hai em đang bất đồng ở điểm nào?"; hoặc Navigator đang làm thay Driver — GV nhắc nhở quy tắc; hoặc cả hai cùng im lặng không tiến triển — GV đặt câu hỏi gợi mở cho cả hai.
4.2.5. Peer Learning — Học từ bạn bè
Bản chất: Peer learning (học từ đồng đẳng) không phải là học sinh giỏi "dạy lại" học sinh yếu — đó là quan hệ một chiều và thiếu tính học thuật. Peer learning đúng nghĩa là hai học sinh cùng nhau khám phá, tranh luận, giải thích cho nhau nghe — và cả hai đều học được điều gì đó từ quá trình đó.
Ba hình thức peer learning phù hợp với GQVĐ Tin học:
Giải thích đồng đẳng (Peer explanation): Học sinh đã giải xong được yêu cầu giải thích cách làm cho bạn chưa giải xong — không được chỉ code mà phải giải thích logic. GV cần hướng dẫn: "Em giải thích cho bạn tại sao em làm vậy, không phải cái gì em làm."
Kiểm tra chéo (Peer testing): Hai học sinh đổi code cho nhau và tìm test case phá được code của bạn. Hình thức này cực kỳ hiệu quả để rèn kỹ năng kiểm thử — học sinh thường cẩn thận hơn khi kiểm tra code của bạn so với code của chính mình.
Phân tích lỗi chéo (Peer debugging): Học sinh A có code lỗi nhờ học sinh B giúp debug — nhưng theo quy trình: B đặt câu hỏi, A tự trả lời và tự phát hiện lỗi. B không được chỉ thẳng vào lỗi.
4.2.6. Tranh luận và phản biện kỹ thuật
Bản chất: Tranh luận kỹ thuật là kỹ năng cao cấp — học sinh không chỉ đề xuất giải pháp mà còn bảo vệ lựa chọn của mình trước câu hỏi, so sánh với giải pháp khác, và thay đổi quan điểm khi có bằng chứng. Đây là cách tư duy của kỹ sư phần mềm thực sự — không phải "ai đúng" mà là "bằng chứng nào, tiêu chí nào".
GV kích hoạt tranh luận kỹ thuật như thế nào:
Khi có hai học sinh giải bài theo hai cách khác nhau đều cho kết quả đúng, GV không vội công nhận cả hai hay chọn một — thay vào đó chiếu cả hai lên màn hình (ẩn tên) và hỏi:
• "Hai cách này khác nhau ở điểm nào?"
• "Mỗi cách có ưu điểm và nhược điểm gì?"
• "Nếu dữ liệu đầu vào có 1 triệu phần tử, cách nào chạy nhanh hơn? Tại sao?"
• "Cách nào dễ đọc và bảo trì hơn? Tại sao?"
Tranh luận kỹ thuật cần tiêu chí cụ thể — không phải "em thích cách nào hơn" mà là "theo tiêu chí hiệu suất/độ đọc được/khả năng mở rộng, cách nào tốt hơn và tại sao".
Kỹ thuật "Bảo vệ lời giải" (Solution Defense):
Học sinh trình bày lời giải của mình trong 2 phút, sau đó nhóm (hoặc GV) đặt câu hỏi phản biện trong 3 phút. Học sinh phải trả lời — không được sửa code trong khi đang bảo vệ. Hình thức này rèn luyện khả năng hiểu sâu về lời giải của chính mình — học sinh không thể bảo vệ được điều họ chỉ sao chép mà không hiểu.
4.2.7. Phân tích lỗi có cấu trúc
Bản chất: Phân tích lỗi không chỉ là sửa code — mà là học từ lỗi. Một lỗi được phân tích đúng cách có giá trị học tập cao hơn nhiều lần so với một lời giải đúng ngay từ đầu. GV cần tạo ra văn hóa lớp học trong đó "mắc lỗi và phân tích lỗi" được coi là hoạt động học tập có giá trị, không phải là thất bại cần che giấu.
Khung phân tích lỗi 4 chiều:
Chiều 1 — Mô tả lỗi: Lỗi gì? Biểu hiện cụ thể như thế nào? (Thông báo lỗi, kết quả sai, chương trình treo...)
Chiều 2 — Định vị lỗi: Lỗi xảy ra ở dòng nào, hàm nào, bước nào trong thuật toán?
Chiều 3 — Nguyên nhân gốc rễ: Tại sao học sinh viết như vậy? Hiểu nhầm khái niệm nào? Thiếu kiến thức gì? Hay chỉ là sơ ý về cú pháp? (Đây là chiều quan trọng nhất — cùng một biểu hiện lỗi có thể có nhiều nguyên nhân khác nhau)
Chiều 4 — Bài học phòng tránh: Làm thế nào để không mắc lỗi này lần sau? Test case nào sẽ phát hiện lỗi này sớm hơn?
Kỹ thuật "Error Museum" (Bảo tàng lỗi):
GV thu thập các lỗi điển hình từ bài làm học sinh (ẩn danh) trong nhiều lớp và nhiều năm, tổ chức thành "bộ sưu tập" phân loại theo loại lỗi. Dùng trong tiết ôn tập hoặc đầu tiết thực hành để học sinh phân tích và dự đoán nguyên nhân trước khi tự làm bài. Hình thức này vừa phát triển kỹ năng debug vừa tạo tâm lý "lỗi là bình thường và có thể học từ đó".
4.2.8. Đánh giá lời giải AI và đọc hiểu code AI
Bản chất và tầm quan trọng: Trong thực tế, học sinh ngày càng sử dụng AI để tạo ra code. Thay vì cấm đoán (thường vô hiệu quả) hoặc chấp nhận thụ động, GV Tin học có trách nhiệm đặc biệt: dạy học sinh đọc hiểu, kiểm chứng và đánh giá phản biện code do AI tạo ra. Đây là kỹ năng nghề nghiệp thiết yếu của kỹ sư phần mềm thời AI.
Năm câu hỏi học sinh phải đặt ra khi nhận code từ AI:
1. Code này có chạy được không? — Chạy thử ngay, không giả định.
2. Code này có cho kết quả đúng không? — Kiểm thử với ít nhất 5 test case bao gồm edge case.
3. Code này làm gì? — Học sinh phải giải thích được từng dòng, không chấp nhận "em không biết nhưng nó chạy".
4. Code này có tốt không? — Đánh giá theo tiêu chí: có thể đọc được không, có hiệu quả không, có xử lý lỗi không.
5. AI có thể sai ở điểm nào? — Phát hiện rủi ro: edge case không được xử lý, giả định ẩn, cách tiếp cận không tối ưu.
Hoạt động "AI Code Review":
GV yêu cầu học sinh dùng AI tạo code cho một bài toán, sau đó thực hiện "code review" theo quy trình:
• Chạy thử với 5 test case (tự thiết kế, không dùng test case AI đề xuất).
• Giải thích từng dòng code bằng lời.
• Tìm ít nhất 2 điểm có thể cải thiện (không nhất thiết phải là lỗi).
• Viết phiên bản cải thiện dựa trên hiểu biết của mình.
Hoạt động này biến AI từ "công cụ tạo đáp án" thành "ngữ liệu học tập" — học sinh học từ code AI như học từ bài giải mẫu, nhưng với tư duy phản biện thay vì sao chép.
________________________________________
4.3. Hình thức tổ chức hoạt động GQVĐ
4.3.1. Phân loại và lựa chọn hình thức tổ chức
Mỗi hình thức tổ chức có thế mạnh riêng và phù hợp với những loại nhiệm vụ khác nhau. GV cần biết khi nào dùng hình thức nào — không có hình thức nào tốt nhất cho mọi tình huống.
Bảng lựa chọn hình thức tổ chức theo đặc điểm nhiệm vụ:
Hình thức Phù hợp nhất khi Không phù hợp khi Lưu ý đặc thù Tin học
Cá nhân Rèn kỹ năng thao tác, kiểm tra năng lực cá nhân, bài tập phân hóa Nhiệm vụ quá khó, học sinh cần giao tiếp để tư duy Mỗi học sinh cần một máy; tránh để màn hình trống > 3 phút
Cặp đôi Pair Programming, peer review, bài tập cần thảo luận ngắn Bài kiểm tra, khi cần đánh giá cá nhân Hai học sinh một máy; phân công Driver-Navigator rõ ràng
Nhóm (3-4) Dự án nhiều hạng mục, thiết kế hệ thống, phân tích CSDL phức tạp Bài tập lập trình ngắn (dễ ỷ lại) Phân công vai trò: Leader, Developer, Tester, Documenter
PBL (Problem-based) Bài toán thực tế mở, đòi hỏi xác định vấn đề trước khi giải Kỹ năng cú pháp cơ bản, bài tập có đáp án duy nhất Học sinh xác định và định hướng vấn đề; GV là người hỗ trợ
PjBL (Project-based) Sản phẩm số nhiều tiết, kết nối nhiều chủ đề Tiết học đơn lẻ, kiến thức chưa đủ Cần kế hoạch dự án rõ ràng, milestone, peer review giữa kỳ
4.3.2. Problem-based Learning (PBL) trong Tin học
Đặc điểm phân biệt với dạy học thông thường: Trong PBL, vấn đề đến trước khi học kiến thức — học sinh gặp bài toán thực tế trước, nhận ra mình thiếu kiến thức gì, rồi học kiến thức đó để giải bài toán. Đây là đảo ngược hoàn toàn so với "dạy lý thuyết → làm bài tập".
Quy trình PBL 7 bước (adapted for Tin học):
Bước Hoạt động Vai trò GV Ví dụ
1. Gặp vấn đề Học sinh đọc tình huống thực tế Cung cấp tình huống đủ phức tạp "Cửa hàng bán 500 mặt hàng, cần phần mềm quản lý tồn kho"
2. Xác định vấn đề Nhóm xác định chính xác cần giải quyết điều gì Đặt câu hỏi làm rõ, không định hướng giải pháp Học sinh tự đặt câu hỏi: cần lưu dữ liệu gì, thao tác gì
3. Brainstorm Đề xuất tự do các giải pháp có thể Im lặng, không đánh giá Học sinh đề xuất nhiều cấu trúc dữ liệu, nhiều giao diện
4. Xác định thiếu hụt kiến thức Nhóm liệt kê những gì chưa biết Hướng dẫn phân loại "biết/chưa biết" Chưa biết cách lưu file, chưa biết cách sắp xếp theo tiêu chí
5. Tự học Học sinh tự tìm hiểu phần thiếu hụt Cung cấp tài nguyên, không giảng dạy trước Học sinh đọc tài liệu, xem video về file I/O
6. Tổng hợp và thực hiện Nhóm ghép kiến thức mới vào giải pháp Hỗ trợ khi bị kẹt Học sinh cài đặt chương trình quản lý tồn kho
7. Trình bày và phản tư Chia sẻ sản phẩm, rút ra bài học Đặt câu hỏi đánh giá và khái quát hóa Demo sản phẩm, thảo luận về thiết kế
4.3.3. Project-based Learning (PjBL) trong Tin học
Phân biệt PBL và PjBL: PBL tập trung vào quá trình giải quyết vấn đề — sản phẩm là kết quả phụ. PjBL tập trung vào sản phẩm cuối cùng — học sinh học thông qua quá trình xây dựng sản phẩm thực sự có giá trị. Trong Tin học, PjBL thường tạo ra sản phẩm số: ứng dụng, website, CSDL hoạt động được, bộ công cụ phân tích dữ liệu.
Bốn đặc trưng của PjBL chất lượng trong Tin học:
Tính thực (authenticity): Sản phẩm giải quyết vấn đề thực tế, không phải bài tập giả lập. Người dùng thực sự (học sinh khác trong trường, giáo viên, phụ huynh) có thể dùng được.
Tính phức tạp vừa phải (appropriate complexity): Đủ phức tạp để học sinh không thể giải một mình trong một tiết — cần cộng tác và nhiều kỹ năng. Không quá phức tạp đến mức nhóm không hoàn thành được trong thời gian cho phép.
Tính lặp đi lặp lại (iteration): Sản phẩm được cải thiện qua nhiều vòng — không phải "làm xong nộp" mà là "làm → nhận phản hồi → cải tiến → nhận phản hồi → cải tiến".
Tính công khai (public audience): Sản phẩm được trình bày trước khán giả thực sự — không chỉ GV chấm điểm mà có bạn cùng lớp, học sinh lớp khác, hoặc thậm chí phụ huynh/cộng đồng.
________________________________________
4.4. Kỹ thuật dạy học đặc thù trong giờ GQVĐ Tin học
4.4.1. Think – Pair – Share (TPS) trong Tin học
Quy trình chuẩn:
• Think (2–3 phút): Học sinh suy nghĩ độc lập — viết ra (không được để trong đầu, phải ghi ra giấy hoặc màn hình).
• Pair (3–5 phút): Chia sẻ với bạn bên cạnh — giải thích cho nhau nghe, tìm điểm đồng và bất đồng.
• Share (5–8 phút): Một số cặp chia sẻ với cả lớp — GV tổng hợp và kết nối các ý kiến.
Ứng dụng đặc thù trong Tin học — 5 tình huống:
TPS cho phân tích đề bài: Trước khi bắt đầu code, học sinh Think viết ra phân tích đề (input, output, ràng buộc), Pair so sánh với bạn xem có điểm nào bỏ sót, Share phát hiện những trường hợp đặc biệt mà cả lớp hay bỏ qua.
TPS cho lựa chọn thuật toán: "Có ba cách giải bài này — cách nào tốt nhất? Think 2 phút, sau đó thuyết phục bạn bên cạnh."
TPS cho debug: Chiếu code lỗi lên màn hình — "Think: em nghĩ lỗi ở đâu và tại sao? Pair: so sánh với bạn. Share: nhóm nào tìm được lỗi và giải thích được nguyên nhân?"
TPS cho đánh giá code AI: Học sinh nhận code từ AI — "Think: 3 điều em thấy tốt và 2 điều em muốn cải thiện. Pair: so sánh nhận xét với bạn."
TPS cho khái quát hóa: Cuối tiết — "Think: bài học lớn nhất em rút ra từ hoạt động hôm nay là gì? Pair: nghe bạn chia sẻ — bạn rút ra điều gì khác em? Share: những pattern tư duy nào xuất hiện nhiều nhất trong lớp?"
4.4.2. Debug Together
Bản chất: Debug Together là kỹ thuật tổ chức cả lớp hoặc nhóm nhỏ cùng debug một đoạn code có lỗi được chiếu lên màn hình chung. Không phải GV chữa lỗi — GV là người dẫn chương trình, học sinh là người phân tích.
Quy trình Debug Together (20 phút):
Pha 1 — Đọc code (3 phút): Cả lớp đọc code được chiếu — không được chạy thử ngay. Học sinh ghi ra giấy những gì họ nghĩ code làm.
Pha 2 — Dự đoán (2 phút): "Theo em, nếu chạy code này với input [X], output sẽ là gì?" — Học sinh ghi dự đoán của mình.
Pha 3 — Chạy thử (1 phút): GV chạy code với input đó. So sánh với dự đoán — có ai dự đoán đúng không? Ai dự đoán sai?
Pha 4 — Phân tích bất đồng (5 phút): "Tại sao output thực tế khác với dự đoán của nhiều bạn? Dòng nào trong code gây ra điều đó?" — Học sinh thảo luận nhóm.
Pha 5 — Đề xuất sửa (3 phút): Mỗi nhóm đề xuất cách sửa — ghi lên bảng hoặc chat.
Pha 6 — Kiểm chứng (3 phút): Thử các cách sửa được đề xuất — cách nào đúng? Tại sao?
Pha 7 — Rút ra bài học (3 phút): "Lỗi này thuộc loại nào? Test case nào sẽ phát hiện lỗi này sớm hơn? Làm sao tránh lỗi này trong tương lai?"
4.4.3. Peer Review có cấu trúc
Bản chất: Peer Review trong Tin học là học sinh đánh giá code/sản phẩm của bạn theo tiêu chí có cấu trúc — không phải "em thích hay không thích" mà là "theo tiêu chí X, sản phẩm này đạt mức nào và tại sao".
Quy trình Peer Review 4 bước:
Bước 1 — Nhận và đọc (5 phút): Nhận code của bạn được phân công. Đọc toàn bộ — không chạy ngay. Viết ra hiểu biết ban đầu: "Code này làm gì?"
Bước 2 — Chạy và kiểm thử (7 phút): Chạy code với ít nhất 4 test case tự thiết kế (không được dùng test case bạn cung cấp sẵn — tự nghĩ ra). Ghi kết quả vào bảng.
Bước 3 — Điền phiếu review (5 phút): Điền phiếu review theo tiêu chí (xem mẫu phiếu dưới đây).
Bước 4 — Thảo luận trực tiếp (3 phút): Hai học sinh gặp nhau, người được review giải thích các lựa chọn thiết kế của mình trước khi nhận phản hồi. Người review đặt câu hỏi, không phê phán.
Mẫu phiếu Peer Review code lập trình:
Tiêu chí Nhận xét cụ thể Đề xuất cải thiện
Tính đúng đắn (kết quả test case)
Xử lý edge case
Tên biến/hàm rõ nghĩa không?
Có comment ở chỗ phức tạp không?
Cấu trúc code dễ đọc không?
Điều em học được từ code này
Một câu hỏi em muốn hỏi tác giả
Lưu ý quan trọng: Peer Review cần được thiết kế để cả hai bên đều học được — người được review không phải là "người có lỗi", người review không phải là "người phán xét". GV cần thiết lập văn hóa này ngay từ đầu.
4.4.4. Gallery Walk trong Tin học
Bản chất: Gallery Walk là hoạt động học sinh đi "tham quan" các sản phẩm của các nhóm khác như tham quan triển lãm, dừng lại tương tác với mỗi "gian hàng" và để lại phản hồi.
Ứng dụng đặc thù trong Tin học:
Gallery Walk sản phẩm số: Mỗi nhóm để lại máy tính với sản phẩm chạy sẵn (website, chương trình, CSDL). Học sinh các nhóm khác đến thử dùng sản phẩm, để lại sticky note (vật lý hoặc số) với nhận xét: điều thích nhất, điều muốn cải thiện, một câu hỏi cho nhóm tác giả.
Gallery Walk code review: Mỗi nhóm in code (hoặc chiếu lên màn hình nhóm) và để lại bên cạnh phiếu comment. Học sinh đi qua, đọc code, viết nhận xét ngắn. Cuối buổi, mỗi nhóm đọc toàn bộ nhận xét nhận được.
Gallery Walk giải pháp đa dạng: Mỗi nhóm viết giải pháp của mình cho cùng một bài toán lên bảng phụ hoặc giấy A0. Cả lớp đi tham quan, so sánh các cách tiếp cận khác nhau.
Quy trình Gallery Walk (35–40 phút):
• 15 phút: Nhóm hoàn thiện sản phẩm/trình bày.
• 15 phút: Tham quan và để lại phản hồi (3–4 phút mỗi gian hàng).
• 5–10 phút: Mỗi nhóm đọc phản hồi nhận được và chọn 2 điểm sẽ cải thiện.
4.4.5. Microteaching trong Tin học
Bản chất và ứng dụng: Microteaching trong Chương 4 không phải là sinh viên luyện tập dạy học (như ở học phần Tổ chức dạy học) mà là học sinh dạy lại một đơn vị kiến thức nhỏ cho các bạn trong nhóm — như một hình thức học tập chủ động (active learning).
Quy trình Microteaching học sinh (15–20 phút/nhóm):
• Chuẩn bị (5 phút): Học sinh được giao một khái niệm/thuật toán nhỏ để giải thích — chuẩn bị ví dụ minh họa, không được đọc từ sách.
• Dạy (3–5 phút): Học sinh "dạy" cho nhóm 3–4 người, được phép dùng màn hình, bảng trắng nhỏ.
• Câu hỏi từ "học sinh" (2–3 phút): Các bạn trong nhóm đặt câu hỏi thực sự — không phải câu hỏi để kiểm tra mà để hiểu sâu hơn.
• Phản hồi (2 phút): Nhóm cho phản hồi theo cấu trúc: điều giải thích rõ nhất, điều muốn nghe thêm.
GV quan sát và ghi chép — microteaching học sinh là nguồn thông tin chẩn đoán quý giá: học sinh giải thích được điều gì cho người khác hiểu là bằng chứng mạnh nhất về mức độ hiểu của bản thân họ.
________________________________________
4.5. Tích hợp AI như đối tác học tập
4.5.1. AI như cộng sự lập trình (AI Pair Programmer)
Vai trò: AI đóng vai Navigator trong mô hình Pair Programming — học sinh là Driver (tự gõ code, tự ra quyết định), AI là Navigator (đề xuất hướng đi, giải thích tùy chọn). Sự khác biệt quan trọng so với "nhờ AI viết code": học sinh vẫn là người kiểm soát và ra quyết định, AI chỉ đề xuất.
Hướng dẫn học sinh dùng AI như Pair Programmer:
Câu hỏi học sinh nên hỏi AI (tập trung vào gợi ý, không yêu cầu giải hộ):
• "Tôi đang cố làm X nhưng chưa biết bắt đầu từ đâu. Bạn có thể gợi ý 2–3 hướng tiếp cận không? Đừng viết code — chỉ mô tả hướng đi thôi."
• "Đây là thuật toán tôi đang nghĩ đến. Bạn thấy có vấn đề gì với logic này không?"
• "Tôi muốn dùng X để giải quyết Y. Cú pháp cơ bản của X là gì?"
Câu hỏi học sinh không nên hỏi AI:
• "Viết code hoàn chỉnh cho bài này."
• "Sửa lỗi này cho tôi."
• "Giải bài tập này."
GV cần thiết lập quy tắc này rõ ràng từ đầu và giải thích lý do sư phạm — không phải vì muốn kiểm soát mà vì học sinh học được nhiều hơn khi tự làm.
4.5.2. AI như công cụ debug
Hướng dẫn sử dụng AI để debug đúng cách:
Quy trình "Hiểu trước, AI sau" áp dụng cho debug:
1. Học sinh tự đọc thông báo lỗi và viết ra phỏng đoán nguyên nhân.
2. Học sinh hỏi AI: "Đây là code của tôi [dán code]. Lỗi tôi đang gặp là [mô tả lỗi]. Tôi nghĩ nguyên nhân có thể là [phỏng đoán của học sinh]. Bạn có thể giải thích tại sao lỗi xảy ra không? Đừng sửa code — chỉ giải thích."
3. Học sinh đọc giải thích của AI, tự sửa code.
4. Học sinh kiểm chứng bằng test case.
Bước quan trọng: sau khi sửa xong, học sinh viết vào worksheet: "Lỗi là gì — Nguyên nhân — Cách sửa — Bài học rút ra." Ghi chép này biến trải nghiệm debug từ việc sửa một lần thành kiến thức lâu dài.
4.5.3. AI như đối tượng phản biện
Bản chất: Thay vì học sinh phản biện bài làm của nhau (áp lực xã hội), học sinh phản biện output của AI — giải phóng tâm lý và tập trung vào kỹ năng tư duy phê phán.
Kịch bản hoạt động "Phản biện AI":
GV yêu cầu AI tạo ra giải pháp cho bài toán đang học. Học sinh nhiệm vụ:
1. Chạy thử code AI — tìm ít nhất 2 test case AI xử lý sai.
2. Giải thích tại sao AI sai ở những điểm đó.
3. Đề xuất cách sửa dựa trên hiểu biết của mình.
4. Rút ra: AI thường gặp khó khăn với loại trường hợp nào?
Hoạt động này kép: vừa phát triển tư duy phê phán về AI, vừa củng cố hiểu biết về bài toán qua việc phân tích lỗi.
4.5.4. AI như nguồn sinh lời giải để học sinh đánh giá
Hoạt động "So sánh lời giải":
Học sinh tự giải bài toán xong, sau đó yêu cầu AI giải cùng bài toán đó. So sánh hai lời giải theo 4 tiêu chí: tính đúng đắn, hiệu quả, độ đọc được, và xử lý edge case. Học sinh viết báo cáo ngắn: "Lời giải của tôi tốt hơn AI ở điểm X. Lời giải của AI tốt hơn tôi ở điểm Y. Tôi sẽ học từ AI điều Z."
Hoạt động này có giá trị cao khi đặt sau khi học sinh đã tự giải — nếu học sinh nhận lời giải AI trước, họ sẽ không có bức tranh độc lập để so sánh.
________________________________________
D. THỰC HÀNH (3 tiết) — MÔ PHỎNG TỔ CHỨC LỚP HỌC
Mục tiêu thực hành
Sinh viên trải nghiệm cả hai vai — vai GV (tổ chức, hỗ trợ, can thiệp) và vai học sinh (giải quyết vấn đề, nhận hỗ trợ, phản hồi) — trong môi trường mô phỏng có cấu trúc, để phát triển phản xạ sư phạm trước khi vào lớp thực.
________________________________________
4.6. Ngân hàng tình huống sư phạm — 15 tình huống điển hình
Mỗi tình huống được trình bày theo cấu trúc: Mô tả → Phân tích → Các lựa chọn can thiệp → Lựa chọn tối ưu và lý do → Câu hỏi thảo luận mở
________________________________________
NHÓM A — TÌNH HUỐNG HỌC SINH KHÔNG TIẾN TRIỂN
________________________________________
TÌNH HUỐNG 1: Học sinh ngồi im không gõ phím
Mô tả: 8 phút sau khi phát bài tập, GV quan sát thấy học sinh H ngồi im, nhìn đề bài, không gõ gì. Màn hình trống. H không giơ tay xin hỗ trợ.
Phân tích: H có thể: (a) không hiểu đề, (b) hiểu đề nhưng không biết bắt đầu từ đâu, (c) có hướng giải nhưng không biết cú pháp, hoặc (d) hiểu lầm là bài này không bắt buộc. GV cần xác định loại khó khăn trước khi can thiệp.
Các lựa chọn can thiệp:
• A: Đi đến và hỏi ngay "Em gặp vấn đề gì?"
• B: Đi đến, nhìn vào đề bài H đang đọc, và hỏi "Em đã xác định được input và output chưa?"
• C: Hỏi từ xa "Em làm đến đâu rồi?" mà không di chuyển đến chỗ H.
• D: Chờ thêm 5 phút — học sinh cần thời gian suy nghĩ.
Lựa chọn tối ưu: B — câu hỏi cụ thể về Bước 1–2 của quy trình GQVĐ giúp GV xác định ngay H đang bị kẹt ở đâu mà không xâm phạm quá sớm. Nếu H trả lời được input/output, chuyển sang câu hỏi Bước 3 (mô hình hóa). Nếu không, đây là dấu hiệu H chưa đọc kỹ đề.
Không nên chọn A vì câu hỏi quá mở — H thường trả lời "không biết" và không tiến thêm được. Không nên chọn D vì 8 phút là đủ để GV cần hành động — chờ thêm lãng phí thời gian học của H.
Câu hỏi thảo luận: Nếu sau câu hỏi về input/output, H vẫn không trả lời được — GV làm gì tiếp theo?
________________________________________
TÌNH HUỐNG 2: Học sinh liên tục xóa và gõ lại
Mô tả: Học sinh T gõ khoảng 5 dòng code, xóa hết, gõ lại, lại xóa. Đã lặp lại 3 lần trong 10 phút. Màn hình không có gì ổn định.
Phân tích: T biết mình muốn làm gì (có động lực) nhưng không hài lòng với cách cài đặt. Đây thường là dấu hiệu của một trong hai: (a) T đang viết code trước khi có kế hoạch rõ ràng — viết rồi thấy sai, xóa, viết lại theo hướng khác; hoặc (b) T bị kẹt ở cú pháp — biết logic nhưng không nhớ cú pháp đúng.
Lựa chọn tối ưu: GV đến, nhìn vào màn hình, hỏi: "Em đang cố làm gì ở đây? Hãy mô tả bằng lời tự nhiên, chưa cần code." Nếu T mô tả được logic nhưng không biết cú pháp → chỉ đến tài liệu/ví dụ. Nếu T không mô tả được logic → T cần quay lại Bước 4 (Lập kế hoạch), GV yêu cầu T viết giả mã trước.
Điểm sư phạm quan trọng: Đây là hội chứng "code trước, nghĩ sau" rất phổ biến ở học sinh học lập trình. GV cần giúp T hình thành thói quen viết giả mã/sơ đồ trước khi viết code — không phải bằng cách nói "em phải làm vậy" mà bằng cách tạo ra trải nghiệm: "Thử viết giả mã 5 dòng trước, rồi ta cùng xem việc viết code có dễ hơn không."
________________________________________
TÌNH HUỐNG 3: Học sinh code rất nhiều nhưng không chạy thử
Mô tả: Học sinh A đã viết được 40 dòng code trong 20 phút nhưng chưa lần nào nhấn Run. Hỏi thăm, A nói "em chưa làm xong".
Phân tích: A đang bỏ qua Bước 6 (Kiểm tra) trong quá trình — viết toàn bộ code rồi mới kiểm tra. Đây là thói quen nguy hiểm: lỗi tích lũy nhiều, khó tìm nguyên nhân. Trong lập trình thực tế, vòng lặp "viết ít — kiểm tra ngay — tiếp tục" (incremental development) là nguyên tắc cơ bản.
Lựa chọn tối ưu: GV đến, hỏi: "Em đã chạy thử chưa? Thử chạy phần đầu của code thôi — chỉ phần nhập và in input xem có hoạt động chưa." Mục tiêu: giúp A hình thành thói quen kiểm tra từng bước nhỏ.
Bài học thiết kế: Đây là lý do tại sao Chương 3 thiết kế "bài tập mẹ — bài tập con" — mỗi bài tập con đủ nhỏ để kiểm tra ngay. Nếu GV thiết kế bài tập con đủ nhỏ, tình huống này ít xảy ra hơn.
________________________________________
NHÓM B — TÌNH HUỐNG LIÊN QUAN ĐẾN TƯƠNG TÁC NHÓM
________________________________________
TÌNH HUỐNG 4: Một thành viên chiếm toàn bộ bàn phím trong Pair Programming
Mô tả: Trong cặp Pair Programming, học sinh X (học tốt hơn) đang gõ code liên tục và giải thích nhanh cho Y nghe. Y ngồi nhìn, thỉnh thoảng gật đầu nhưng không tham gia.
Phân tích: Cặp đã mất đi mô hình Pair Programming — trở thành "X làm, Y xem". Y không được rèn luyện kỹ năng Driver, và thực ra không chắc Y đang hiểu gì. X dù làm tốt nhưng mất đi cơ hội phát triển kỹ năng Navigator.
Lựa chọn tối ưu: GV đến và nói: "Đã đến giờ đổi vai chưa? Y, em lấy bàn phím đi — X, em chuyển sang vai Navigator, chỉ được đặt câu hỏi thôi nhé." Sau đó đứng quan sát 2–3 phút để đảm bảo sự chuyển giao thực sự diễn ra.
Câu hỏi thảo luận: Nếu Y lấy bàn phím nhưng ngồi im không biết gõ gì tiếp — điều đó cho thấy điều gì? GV làm gì?
________________________________________
TÌNH HUỐNG 5: Nhóm tranh luận gay gắt không ra được quyết định
Mô tả: Nhóm 4 học sinh đã tranh luận 8 phút về việc nên dùng list hay dict để lưu dữ liệu học sinh. Hai em bảo list, hai em bảo dict. Không ai nhường.
Phân tích: Đây thực ra là tình huống học tập tốt — tranh luận kỹ thuật có căn cứ. Vấn đề là nhóm cần tiêu chí quyết định, không phải thêm thời gian tranh luận. GV không nên phán xét "cái nào đúng" mà giúp nhóm tìm tiêu chí.
Lựa chọn tối ưu: GV đến, hỏi: "Hai phương án đều có thể đúng — vấn đề là với bài toán này, tiêu chí nào quan trọng hơn? Tốc độ truy xuất? Dễ thêm/xóa? Dễ đọc? Em hãy liệt kê tiêu chí rồi đánh giá từng phương án." GV không cho đáp án mà cho phương pháp ra quyết định.
Điểm sư phạm: Đây là cơ hội dạy kỹ năng ra quyết định kỹ thuật — rất có giá trị nghề nghiệp. GV nên trân trọng tình huống này, không vội chấm dứt tranh luận.
________________________________________
TÌNH HUỐNG 6: Học sinh sao chép code của bạn
Mô tả: GV quan sát thấy học sinh B đang nhìn màn hình của A bên cạnh và gõ theo từng dòng. B không hỏi A giải thích gì cả.
Phân tích: Sao chép không học được gì — B không hiểu code đang gõ. Nhưng hành vi này thường xuất phát từ áp lực (sợ không xong) hoặc thiếu tự tin (không nghĩ mình có thể làm được). Cần xử lý nguyên nhân gốc, không chỉ hành vi bề mặt.
Lựa chọn tối ưu: GV đến chỗ B, không đề cập đến việc sao chép ngay. Hỏi B: "Em đang làm đến bước nào rồi? Giải thích cho thầy/cô nghe em đang cố làm gì." Nếu B không giải thích được, GV biết B thực sự chưa hiểu. Lúc đó mới nói: "Thầy/cô thấy em đang nhìn bài bạn — điều đó không giúp em học được kỹ năng này. Em nói cho thầy/cô nghe em đang bị kẹt ở bước nào để mình tìm cách khác nhé."
Không nên phê bình B trước lớp — gây xấu hổ không giải quyết vấn đề học tập.
________________________________________
NHÓM C — TÌNH HUỐNG LIÊN QUAN ĐẾN AI
________________________________________
TÌNH HUỐNG 7: Học sinh dùng AI viết toàn bộ code
Mô tả: Học sinh C dùng điện thoại hỏi ChatGPT, nhận code hoàn chỉnh, copy vào IDE và nộp. Khi GV hỏi "Em giải thích dòng này làm gì?", C ấp úng không trả lời được.
Phân tích: C đã bỏ qua toàn bộ mục tiêu học tập của bài. Code đúng nhưng C không học gì. Đây là vấn đề liêm chính học thuật, nhưng cũng là vấn đề thiết kế — nếu bài tập chỉ đánh giá sản phẩm cuối (code đúng/sai), học sinh có động lực dùng AI. Nếu đánh giá quá trình (worksheet, giải thích, test case tự thiết kế), động lực này giảm đi.
Lựa chọn tối ưu ngắn hạn: GV yêu cầu C giải thích từng dòng code — "Em không cần làm bài lại ngay, nhưng hãy đọc code này và giải thích cho thầy/cô dòng số 5 làm gì." Đây là hình thức "oral defense" — nếu C hiểu, không sao; nếu không hiểu, C nhận ra hậu quả của việc dùng AI không có chọn lọc.
Lựa chọn dài hạn: Thiết kế lại bài tập (Chương 3) để quá trình không thể bị AI thay thế hoàn toàn: worksheet yêu cầu ghi lại từng bước tư duy, test case tự thiết kế, phần phản tư cá nhân.
________________________________________
TÌNH HUỐNG 8: Học sinh tin tưởng hoàn toàn vào code AI mà không kiểm tra
Mô tả: Học sinh D dùng AI sinh ra code, code chạy không báo lỗi, D nộp ngay. Code thực ra có lỗi logic với một edge case cụ thể.
Phân tích: D tin rằng "AI không sai" — đây là misconception quan trọng cần sửa. AI có thể tạo ra code chạy được nhưng logic sai, đặc biệt với edge case. Đây là cơ hội dạy tư duy kiểm thử và tư duy phản biện về AI.
Lựa chọn tối ưu: GV chạy code với test case phá lỗi trước lớp (ẩn tên D). "Code này chạy tốt với input thông thường. Thử với input [-1, 0, 0] — kết quả thế nào? Tại sao AI lại tạo ra code có lỗi như vậy?" Dùng tình huống này để dạy cả lớp về giới hạn của AI.
________________________________________
TÌNH HUỐNG 9: Học sinh dùng AI đúng cách và học được nhiều
Mô tả: Học sinh E hỏi AI: "Tôi đang cố làm X nhưng chưa biết thuật toán nào phù hợp. Bạn có thể đề xuất 2–3 hướng tiếp cận không, kèm ưu nhược điểm?" E đọc phản hồi AI, chọn một hướng, tự cài đặt, và đang kiểm tra kết quả.
Phân tích: E đang dùng AI đúng vai trò — AI là Navigator gợi ý hướng, E là Driver tự quyết định và cài đặt. Đây là hình mẫu GV muốn cả lớp học theo.
Lựa chọn tối ưu: GV đến, hỏi E giải thích lựa chọn, sau đó chia sẻ với cả lớp (có hỏi phép E): "Em E đang dùng AI theo cách rất thú vị — em chia sẻ được không?" Biến E thành mô hình học tập cho lớp.
________________________________________
NHÓM D — TÌNH HUỐNG VỀ TIẾN ĐỘ VÀ PHÂN HÓA
________________________________________
TÌNH HUỐNG 10: Một nửa lớp chưa bắt đầu được khi đã qua 15 phút
Mô tả: 15 phút vào giờ thực hành, GV nhận ra khoảng 15/30 học sinh vẫn chưa gõ được dòng code nào có ý nghĩa. GV chỉ còn 30 phút thực hành.
Phân tích: Đây là tình huống hệ thống — nhiều học sinh cùng bị kẹt cho thấy có điều gì đó trong thiết kế bài tập hoặc kiến thức nền của lớp không đủ. Không phải vấn đề cá nhân.
Lựa chọn tối ưu: GV dừng cả lớp lại (nhẹ nhàng, không tạo áp lực), nói: "Thầy/cô thấy nhiều bạn đang gặp khó khăn với bước bắt đầu — vậy mình cùng làm phần phân tích đề bài chung 5 phút, sau đó các em tiếp tục." GV dẫn dắt Bước 1–2 (Đọc đề, Phân tích) chung cả lớp — không làm thay Bước 4–5. Sau đó học sinh tiếp tục độc lập từ Bước 3 trở đi.
Câu hỏi thảo luận: Đây là quyết định khó — dừng cả lớp có thể ảnh hưởng đến nhóm đã tiến được rồi. GV xử lý nhóm đó như thế nào?
________________________________________
TÌNH HUỐNG 11: Học sinh hoàn thành quá sớm và bắt đầu mất tập trung
Mô tả: 20 phút vào tiết, học sinh G đã hoàn thành cả bài tập Tầng 1 và Tầng 2. G bắt đầu lướt web.
Phân tích: Bài Tầng 3 (bài tập nâng cao) chưa đủ hấp dẫn với G, hoặc G chưa biết đến Tầng 3. GV cần can thiệp ngay — không phải để phạt G mà để giữ động lực học tập.
Lựa chọn tối ưu: GV đến, xem nhanh bài G, xác nhận G đã làm đúng, sau đó: "Em làm tốt lắm. Em đã thử Tầng 3 chưa? Nếu đã xong Tầng 3, thầy/cô có thêm thách thức: em hãy tìm test case phá code của bạn bên cạnh." Peer testing vừa là bài tập nâng cao vừa tạo ra tương tác có giá trị.
________________________________________
TÌNH HUỐNG 12: Học sinh yếu bị bỏ lại phía sau ngày càng xa
Mô tả: Học sinh K liên tục không hoàn thành được bài tập cơ bản trong nhiều tiết. Các bạn trong lớp đã làm đến bài kết hợp, K vẫn đang làm bài tập đơn giản từ tuần trước.
Phân tích: K đang trong vòng xoáy thất bại — mỗi tiết học lại tụt xa hơn, mỗi lần tụt xa hơn lại càng mất động lực. Đây là vấn đề cần can thiệp sớm và có kế hoạch, không thể giải quyết trong một tiết.
Lựa chọn ngắn hạn: Gặp K riêng sau giờ học, tìm hiểu nguyên nhân (thiếu kiến thức nền, vấn đề ở nhà, thiếu tự tin...). Thiết kế lộ trình riêng cho K — không phải "làm bài của lớp" mà là "đạt mục tiêu cốt lõi theo tốc độ của K".
Lựa chọn dài hạn: Review lại thiết kế scaffold và bài tập — nếu K không phải cá biệt mà nhiều học sinh cùng tụt hậu, đó là dấu hiệu scaffold chưa đủ hoặc mức độ phân hóa chưa tốt.
________________________________________
NHÓM E — TÌNH HUỐNG KỸ THUẬT VÀ BẤT NGỜ
________________________________________
TÌNH HUỐNG 13: Học sinh phát hiện cách giải hay hơn GV
Mô tả: Trong khi cả lớp đang dùng thuật toán GV hướng dẫn, học sinh M tìm ra cách giải ngắn hơn nhiều và hỏi GV: "Thầy/cô ơi, em làm theo cách này được không? Em thấy nó ngắn hơn."
Phân tích: Đây là khoảnh khắc học tập có giá trị nhất trong giờ học — không phải vấn đề cần quản lý mà là cơ hội cần nắm bắt. GV phản ứng như thế nào trong khoảnh khắc này sẽ ảnh hưởng đến văn hóa lớp học: có an toàn để khám phá và đề xuất hay không?
Lựa chọn tối ưu: GV nhìn vào cách M làm, kiểm tra tính đúng đắn (không vội khen hay chê), sau đó: "Cách của em thú vị lắm. Em hãy kiểm thử với 5 test case này xem có đúng không. Nếu đúng, mình chia sẻ với cả lớp." Sau đó chia sẻ với cả lớp và phân tích tại sao cách của M hay hơn — điều này dạy cả lớp tư duy tối ưu và khuyến khích M tiếp tục khám phá.
Câu hỏi thảo luận: Nếu cách của M ngắn hơn nhưng GV không chắc chắn là đúng hoàn toàn — GV làm gì?
________________________________________
TÌNH HUỐNG 14: Học sinh hỏi câu hỏi vượt nội dung bài
Mô tả: Trong khi lớp đang học vòng lặp cơ bản, học sinh N hỏi: "Thầy/cô ơi, em đọc được rằng Python có thể dùng list comprehension để thay thế vòng lặp for, như vậy có nhanh hơn không?"
Phân tích: N đang tự học mở rộng — đây là biểu hiện tốt. Câu hỏi thực sự có giá trị. Nhưng GV cần cân bằng giữa việc khuyến khích N và không làm cả lớp bị phân tâm.
Lựa chọn tối ưu: "Câu hỏi hay lắm. List comprehension thực ra là chủ đề mình sẽ học sau. Bây giờ em hãy thử tự tìm hiểu và sau tiết mình nói chuyện thêm nhé. Nếu em muốn, em thử viết lại bài tập hôm nay dùng list comprehension xem có đúng không." Đây vừa khuyến khích N vừa biến câu hỏi thành nhiệm vụ mở rộng.
________________________________________
TÌNH HUỐNG 15: Toàn lớp gặp khó ở cùng một bước
Mô tả: GV quan sát thấy nhiều học sinh bị kẹt ở cùng một điểm — sử dụng biến flag sau vòng lặp để xác định kết quả. Nhiều học sinh hỏi cùng câu hỏi về điều này.
Phân tích: Đây là dấu hiệu thiết kế bài tập hoặc scaffold chưa đủ ở điểm này (đây là "điểm khó" đã được xác định trong phân tích nhiệm vụ ở Chương 3). GV cần can thiệp ở cấp độ lớp, không phải cá nhân.
Lựa chọn tối ưu: GV dừng lớp, dạy "mini-lesson" 5 phút về biến flag. Không giải thích bài tập cụ thể mà giải thích khái niệm tổng quát với một ví dụ nhỏ hơn, đơn giản hơn. Sau đó để học sinh tự áp dụng vào bài của mình.
Bài học thiết kế: Tình huống 15 cho thấy GV cần thiết kế scaffold cho điểm khó này ở Chương 3 — nếu nhiều lớp cùng gặp khó ở đây, scaffold hiện tại không đủ.
________________________________________
4.7. Tiến trình thực hành — 3 tiết mô phỏng lớp học
Tiết thực hành 1: Phân tích tình huống và xây dựng phản xạ
Hoạt động 1 — Think-Pair-Share phân tích tình huống (30 phút):
GV chia 15 tình huống cho các nhóm (mỗi nhóm 2–3 tình huống). Mỗi nhóm phân tích theo khung:
1. Loại khó khăn của học sinh là gì?
2. Bước GQVĐ nào đang gặp vấn đề?
3. Đề xuất can thiệp theo 3 mức scaffold.
4. Rủi ro nếu can thiệp sai cách.
Nhóm trình bày → lớp tranh luận → GV chốt nguyên tắc.
Hoạt động 2 — Xây dựng "Cẩm nang phản xạ GV" (15 phút):
Cá nhân mỗi sinh viên viết ra 5 tình huống mình lo ngại nhất khi vào dạy thật, và phương án xử lý cụ thể cho mỗi tình huống. Đây là tài liệu cá nhân — không chấm điểm, nhưng là bước chuẩn bị tâm lý quan trọng.
Tiết thực hành 2: Roleplay — Mô phỏng giờ GQVĐ
Cấu trúc roleplay:
• Nhóm 6 sinh viên: 1 sinh viên đóng vai GV, 5 sinh viên đóng vai học sinh với các trạng thái được phân công (ví dụ: HS A — không hiểu đề; HS B — có hướng giải nhưng bị kẹt cú pháp; HS C — làm xong sớm; HS D — đang dùng AI không đúng cách; HS E — bị kẹt lỗi logic nhưng không biết).
• GV mô phỏng tổ chức 20 phút giờ thực hành: di chuyển, quan sát, can thiệp.
• Sau 20 phút: dừng lại, cả nhóm phân tích từng quyết định can thiệp của GV.
• Luân phiên để mỗi sinh viên đều được làm vai GV ít nhất một lần.
Phiếu quan sát cho người không đóng vai GV:
Thời điểm GV đang làm gì Em sẽ làm gì thay thế Lý do
Tiết thực hành 3: Microteaching và tổng kết
Microteaching hỗ trợ debugging (25 phút):
Mỗi sinh viên chuẩn bị một đoạn code có lỗi logic (không phải lỗi cú pháp đơn giản) và "dạy" nhóm 4–5 người cách phát hiện lỗi đó thông qua câu hỏi Socratic — không được chỉ ra lỗi trực tiếp, chỉ được đặt câu hỏi.
Sau mỗi microteaching: nhóm phản hồi — câu hỏi nào hiệu quả nhất? Câu hỏi nào vô tình tiết lộ đáp án?
Tổng kết và kết nối với Chương 5 (10 phút):
GV chốt: "Toàn bộ chương 4 xoay quanh một câu hỏi: khi học sinh đang giải quyết vấn đề, GV ở đâu và làm gì? Chương 5 sẽ đi tiếp: sau khi hoạt động kết thúc, làm thế nào để đánh giá — không phải chỉ đánh giá sản phẩm mà đánh giá năng lực GQVĐ của học sinh?"
________________________________________
E. RUBRIC ĐÁNH GIÁ NĂNG LỰC TỔ CHỨC VÀ HỖ TRỢ (dùng trong roleplay và thực tập)
Tiêu chí Tốt (3đ) Đạt (2đ) Chưa đạt (1đ)
Phát hiện khó khăn Chủ động quan sát, phát hiện đúng loại và bước khó khăn trước khi HS giơ tay Phát hiện khi HS giơ tay; xác định đúng bước nhưng chưa xác định loại Chờ HS giơ tay; không xác định được bước đang gặp khó
Mức độ scaffold Bắt đầu với scaffold tối thiểu; tăng dần khi cần; không làm thay Scaffold đúng hướng nhưng đôi khi quá nhiều hoặc quá ít Giải thích trực tiếp hoặc làm thay; hoặc không hỗ trợ gì
Câu hỏi gợi mở Câu hỏi mở, không tiết lộ đáp án, dẫn HS đến bước tư duy tiếp theo Câu hỏi tốt nhưng đôi khi quá gợi ý Câu hỏi đóng (Có/Không) hoặc chứa đáp án
Quy tắc tay không chạm bàn phím Nhất quán tuân thủ trong suốt roleplay Vi phạm 1–2 lần nhưng tự sửa Vi phạm nhiều lần hoặc không nhận ra
Tổ chức không gian và thời gian Di chuyển có chủ đích; phân bổ thời gian hỗ trợ hợp lý; không bỏ sót HS Di chuyển khá tốt; đôi khi tập trung quá lâu vào một HS Đứng yên hoặc di chuyển ngẫu nhiên; một số HS không được chú ý
Tích hợp AI Hướng dẫn HS dùng AI đúng vai trò; can thiệp khi HS dùng AI thay thế tư duy Có nhắc về AI nhưng chưa có hướng dẫn cụ thể Không đề cập AI hoặc cấm AI mà không giải thích
Tổng: 18 điểm → Quy về 10
________________________________________
F. TÀI LIỆU THAM KHẢO
• Vygotsky, L. S. (1978). Mind in Society. Harvard University Press.
• Wood, D., Bruner, J. S., & Ross, G. (1976). The role of tutoring in problem solving. Journal of Child Psychology and Psychiatry, 17(2), 89–100.
• Williams, L., & Kessler, R. (2002). Pair Programming Illuminated. Addison-Wesley.
• Barrows, H. S. (1986). A taxonomy of problem-based learning methods. Medical Education, 20(6), 481–486.
• Thomas, J. W. (2000). A Review of Research on Project-Based Learning. Autodesk Foundation.
• Rowe, M. B. (1986). Wait time: Slowing down may be a way of speeding up! Journal of Teacher Education, 37(1), 43–50.
• Lyman, F. (1981). The responsive classroom discussion. Mainstreaming Digest, University of Maryland.
• UNESCO (2023). Guidance for generative AI in education and research.
• Bộ GD&ĐT (2018). Chương trình giáo dục phổ thông môn Tin học (Thông tư 32/2018/TT-BGDĐT).
CHƯƠNG 5: ĐÁNH GIÁ HOẠT ĐỘNG GIẢI QUYẾT VẤN ĐỀ TRONG DẠY HỌC TIN HỌC
Thời lượng: 6 tiết (3 tiết lý thuyết + 3 tiết thực hành)
________________________________________
A. VỊ TRÍ CHƯƠNG TRONG HỌC PHẦN
Chương 3 thiết kế hoạt động. Chương 4 tổ chức và hỗ trợ học sinh trong giờ học. Chương 5 trả lời câu hỏi cuối cùng nhưng không kém phần quan trọng: làm thế nào biết học sinh đã học được gì? Đây không phải là câu hỏi về chấm điểm — mà là câu hỏi về bằng chứng học tập. Đánh giá trong dạy học GQVĐ Tin học phức tạp hơn đánh giá truyền thống ở chỗ: sản phẩm cuối (code chạy đúng hay sai) chỉ là một phần nhỏ của bức tranh — quá trình tư duy, chiến lược giải quyết, tư duy tính toán, khả năng hợp tác và mức độ sử dụng AI có trách nhiệm đều cần được đánh giá, nhưng không thể đo bằng bài kiểm tra truyền thống.
Chương 5 có thêm một đặc thù quan trọng so với các tài liệu đánh giá truyền thống: bối cảnh AI tạo sinh đặt ra những thách thức đánh giá hoàn toàn mới — khi học sinh có thể nhận code từ AI, GV cần đánh giá được học sinh thực sự hiểu gì, không chỉ đánh giá sản phẩm học sinh nộp lên.
________________________________________
B. MỤC TIÊU CHƯƠNG
Sau chương này, sinh viên có thể:
• Phân biệt và thiết kế được đánh giá theo 6 chiều: quá trình, sản phẩm, chiến lược GQVĐ, tư duy tính toán, hợp tác, AI Literacy.
• Thiết kế được 5 công cụ đánh giá: rubric, checklist, portfolio, nhật ký học tập, AI log — với tiêu chí cụ thể, quan sát được, phù hợp mục tiêu.
• Xây dựng được bộ đánh giá trong bối cảnh AI: đánh giá prompt, phản biện AI, chỉnh sửa lời giải AI, sử dụng AI có trách nhiệm.
• Hoàn thành một bộ công cụ đánh giá hoàn chỉnh cho một hoạt động GQVĐ cụ thể trong chương trình Tin học phổ thông.
________________________________________
C. NỀN TẢNG LÝ LUẬN — ĐỌC TRƯỚC KHI VÀO NỘI DUNG
Hai triết lý đánh giá và vị trí của chương này
Đánh giá kết quả học tập (Assessment OF Learning): Đánh giá diễn ra sau khi học xong, mục tiêu là xác nhận học sinh đạt hay không đạt chuẩn. Ví dụ: bài kiểm tra cuối chương, bài thi học kỳ. Kết quả dùng để xếp loại, báo cáo.
Đánh giá vì học tập (Assessment FOR Learning): Đánh giá diễn ra trong quá trình học, mục tiêu là cung cấp thông tin để GV điều chỉnh dạy học và học sinh tự điều chỉnh học tập. Ví dụ: quan sát trong giờ thực hành, phiếu phản tư cuối tiết, peer review giữa chừng. Kết quả dùng để cải thiện, không phải để xếp loại.
Đánh giá là học tập (Assessment AS Learning): Học sinh tự đánh giá và đánh giá lẫn nhau như một hành động học tập — không phải để nhận điểm mà để phát triển metacognition (tư duy về tư duy của chính mình). Ví dụ: nhật ký học tập, self-assessment checklist, peer review có cấu trúc.
Chương này tập trung vào cả ba, với nhấn mạnh đặc biệt vào hai loại sau — vì đây là những gì còn thiếu nhất trong thực tiễn dạy học Tin học hiện nay. Đánh giá trong dạy học GQVĐ không thể chỉ là "code đúng = điểm cao, code sai = điểm thấp" — tư duy như vậy bỏ qua toàn bộ quá trình học tập có giá trị nhất.
Tại sao đánh giá trong dạy học GQVĐ khó hơn
Ba đặc thù của GQVĐ Tin học làm cho đánh giá trở nên phức tạp:
Thứ nhất, con đường đến kết quả quan trọng không kém kết quả: Hai học sinh cùng nộp code đúng nhưng một em tự thiết kế thuật toán, một em nhận gợi ý từ bạn rồi cài đặt — giá trị học tập khác nhau hoàn toàn, nhưng sản phẩm cuối giống hệt nhau.
Thứ hai, nhiều mục tiêu học tập quan trọng không thể quan sát qua sản phẩm: Tư duy tính toán, chiến lược GQVĐ, quản lý thất bại khi debug, khả năng tự điều chỉnh — tất cả đều ẩn bên trong quá trình, không hiện ra trong file code cuối.
Thứ ba, AI tạo ra vấn đề "sản phẩm không phản ánh năng lực": Khi học sinh có thể nhận code hoàn chỉnh từ AI trong 10 giây, đánh giá dựa trên sản phẩm cuối mà không đánh giá quá trình trở nên vô nghĩa về mặt sư phạm.
________________________________________
D. NỘI DUNG LÝ THUYẾT (3 tiết)
________________________________________
5.1. Sáu chiều đánh giá trong hoạt động GQVĐ Tin học
Sáu chiều đánh giá không độc lập mà tạo thành một hệ thống bổ sung cho nhau. Mỗi chiều nhìn vào một khía cạnh khác nhau của cùng một hoạt động học tập. GV không nhất thiết đánh giá cả sáu chiều trong mỗi hoạt động — nhưng cần ý thức chọn lựa: đánh giá chiều nào, bỏ chiều nào, và tại sao.
________________________________________
5.1.1. Đánh giá quá trình (Process Assessment)
Bản chất: Đánh giá quá trình không hỏi "em làm ra gì" mà hỏi "em đã đi qua những bước nào để làm ra điều đó". Căn cứ đánh giá không phải sản phẩm cuối mà là bằng chứng về tiến trình tư duy học sinh đã trải qua trong quy trình GQVĐ 8 bước.
Bằng chứng quá trình có thể thu thập:
Bước GQVĐ Bằng chứng quá trình Cách thu thập
Đọc đề Phần "Phân tích đề bài" trong worksheet (input, output, ràng buộc) Worksheet Phần 1
Phân tích Danh sách trường hợp đặc biệt học sinh tự phát hiện Worksheet Phần 2
Mô hình hóa Sơ đồ/bảng/ký hiệu học sinh vẽ ra Worksheet Phần 3
Lập kế hoạch Giả mã/sơ đồ khối trước khi viết code Worksheet Phần 4
Thực hiện Lịch sử commit (nếu dùng Git), hoặc ảnh màn hình qua các mốc Git log / ảnh chụp
Kiểm tra Bảng test case học sinh tự thiết kế Worksheet Phần 6
Đánh giá Phần phản tư trong worksheet Worksheet Phần 7
Khái quát hóa Nhật ký học tập sau hoạt động Nhật ký học tập
Những gì đánh giá quá trình tiết lộ mà đánh giá sản phẩm không thấy:
Một học sinh nộp code sai nhưng có worksheet hoàn chỉnh với giả mã đúng hướng, bảng test case chi tiết và phần phản tư sâu sắc cho thấy năng lực GQVĐ cao hơn nhiều so với học sinh nộp code đúng nhưng worksheet trống và không có bằng chứng tư duy nào. Đánh giá chỉ dựa trên code cuối sẽ đánh giá sai hoàn toàn hai học sinh này.
5.1.2. Đánh giá sản phẩm (Product Assessment)
Bản chất: Đây là chiều đánh giá truyền thống nhất và không thể bỏ qua — sản phẩm vẫn là bằng chứng quan trọng về năng lực. Tuy nhiên, cần đánh giá sản phẩm theo nhiều tiêu chí chứ không chỉ "đúng/sai".
Bốn tiêu chí đánh giá sản phẩm trong Tin học:
Tính đúng đắn (Correctness): Sản phẩm có cho ra kết quả đúng với các bộ test case không? Đây là tiêu chí cần thiết nhưng không đủ. Cần phân biệt: đúng với test case thông thường (chứng minh học sinh hiểu bài toán cơ bản) và đúng với edge case (chứng minh học sinh phân tích đủ sâu).
Tính hoàn chỉnh (Completeness): Sản phẩm có đáp ứng đủ tất cả yêu cầu của đề bài không? Xử lý tất cả trường hợp được mô tả? Có giao diện/output đúng định dạng yêu cầu?
Chất lượng kỹ thuật (Technical quality): Code có dễ đọc không (tên biến rõ nghĩa, cấu trúc logic, có comment)? Thuật toán có hợp lý không (không dư thừa, không quá phức tạp so với bài toán)? Có xử lý ngoại lệ không?
Tính sáng tạo và tối ưu (Creativity and optimization): Học sinh có đề xuất cải tiến, phương án thay thế, hoặc giải pháp vượt yêu cầu không? Tiêu chí này chỉ áp dụng ở mức đánh giá nâng cao và không nên bắt buộc với học sinh yếu.
Rubric đánh giá sản phẩm mẫu (xem mục 5.2.1 chi tiết hơn):
Tiêu chí 4 — Xuất sắc 3 — Đạt 2 — Cần cải thiện 1 — Chưa đạt
Tính đúng đắn Đúng với tất cả test case kể cả edge case Đúng với test case thông thường, sai 1–2 edge case Đúng với 50–70% test case Sai với phần lớn test case
Tính hoàn chỉnh Đáp ứng 100% yêu cầu + bổ sung thêm Đáp ứng 100% yêu cầu chính Đáp ứng 70–90% yêu cầu Dưới 70% yêu cầu
Chất lượng kỹ thuật Tên biến rõ nghĩa, có comment, cấu trúc logic rõ Tên biến chấp nhận được, cấu trúc đọc được Tên biến khó hiểu hoặc thiếu comment quan trọng Code khó đọc, không có cấu trúc
5.1.3. Đánh giá chiến lược giải quyết vấn đề (Problem-solving Strategy Assessment)
Bản chất: Chiều đánh giá này nhìn vào việc học sinh chọn và sử dụng chiến lược tư duy như thế nào trong quá trình GQVĐ — không phải kết quả mà là cách tiếp cận. Đây là chiều phản ánh trực tiếp mức độ phát triển tư duy của học sinh, không phải chỉ mức độ nắm kiến thức.
Bốn chiến lược GQVĐ cần đánh giá trong Tin học:
Chiến lược phân rã vấn đề: Học sinh có tự chia bài toán lớn thành các bài toán con không? Có viết giả mã/sơ đồ trước khi code không? Hay nhảy thẳng vào code ngay khi đọc xong đề?
Chiến lược thử và sửa (Iterative refinement): Khi gặp lỗi, học sinh phản ứng thế nào? Có đọc thông báo lỗi không? Có thử debug có hệ thống không? Hay xóa hết và viết lại ngẫu nhiên?
Chiến lược tận dụng kiến thức đã có (Pattern recognition): Học sinh có nhận ra bài toán này tương tự bài nào đã học không? Có chủ động áp dụng mẫu tư duy đã biết không?
Chiến lược kiểm soát quá trình (Self-regulation): Học sinh có theo dõi tiến trình của mình không? Có biết mình đang ở bước nào, cần làm gì tiếp theo không? Có điều chỉnh kế hoạch khi gặp trở ngại không?
Công cụ đánh giá chiến lược: Quan sát trực tiếp trong giờ + nhật ký học tập + phần phản tư trong worksheet. Không thể đánh giá chiến lược chỉ qua sản phẩm cuối.
Thang đánh giá chiến lược GQVĐ (4 mức):
Mức 4 — Chiến lược linh hoạt và có ý thức: Học sinh chủ động lựa chọn chiến lược phù hợp với từng loại bài toán, điều chỉnh khi gặp trở ngại, và giải thích được tại sao mình chọn cách tiếp cận đó.
Mức 3 — Chiến lược nhất quán nhưng chưa linh hoạt: Học sinh có chiến lược rõ ràng (ví dụ: luôn phân rã và viết giả mã trước) nhưng áp dụng cứng nhắc cho mọi bài toán, kể cả khi không phù hợp.
Mức 2 — Chiến lược rời rạc, không nhất quán: Học sinh đôi khi dùng chiến lược tốt (sau khi được GV nhắc), đôi khi bỏ qua — chưa có thói quen.
Mức 1 — Không có chiến lược: Học sinh tiếp cận bài toán ngẫu nhiên, không có kế hoạch, phản ứng theo bản năng.
5.1.4. Đánh giá tư duy tính toán (Computational Thinking Assessment)
Bản chất: CT không phải là kỹ năng lập trình — đây là điểm cần nhấn mạnh lại (đã học ở Chương 1). Học sinh có thể viết code tốt mà CT yếu (code theo mẫu mà không hiểu tại sao), và ngược lại, CT mạnh mà code chưa thành thạo. Đánh giá CT đòi hỏi công cụ riêng, không thể dùng bài kiểm tra code thông thường.
Khung đánh giá 4 thành phần CT — áp dụng cho Tin học phổ thông:
Đánh giá Phân rã (Decomposition):
Bằng chứng tốt: Học sinh tự chia bài toán thành các phần nhỏ mà không cần GV gợi ý; giải thích được tại sao cần tách theo cách đó; có thể giải quyết từng phần độc lập.
Câu hỏi đánh giá: "Bài toán này gồm những vấn đề con nào? Em giải chúng theo thứ tự nào và tại sao?"
Biểu hiện qua sản phẩm: Code có cấu trúc hàm/module rõ ràng, mỗi hàm làm một việc, có thể test từng hàm độc lập.
Đánh giá Nhận dạng mẫu (Pattern Recognition):
Bằng chứng tốt: Học sinh tự liên hệ bài toán mới với bài toán đã làm; nhận ra cấu trúc lặp lại; áp dụng đúng mẫu giải pháp đã học vào bối cảnh mới.
Câu hỏi đánh giá: "Em đã từng gặp bài toán nào tương tự bài này chưa? Điểm giống và khác nhau là gì? Em có thể tận dụng kinh nghiệm từ bài đó cho bài này không?"
Biểu hiện qua sản phẩm: Code tái sử dụng đúng pattern đã học (accumulator, sentinel loop, divide-and-conquer...) mà không cần GV nhắc.
Đánh giá Trừu tượng hóa (Abstraction):
Bằng chứng tốt: Học sinh biết bỏ qua chi tiết không cần thiết; thiết kế được hàm/module tổng quát thay vì code cứng cho từng trường hợp cụ thể; giải thích được "cái gì quan trọng, cái gì có thể bỏ qua".
Câu hỏi đánh giá: "Nếu thay đổi yêu cầu từ X thành Y, code của em cần sửa ở đâu? Nếu cần sửa nhiều chỗ, điều đó nói lên gì về thiết kế?"
Biểu hiện qua sản phẩm: Hàm có tham số thay vì giá trị cứng; code hoạt động đúng với nhiều bộ dữ liệu khác nhau không cần sửa.
Đánh giá Thuật toán hóa (Algorithm Design):
Bằng chứng tốt: Học sinh viết được giả mã/sơ đồ khối trước khi code; thuật toán đủ chi tiết để người khác cài đặt được; có xét đến độ phức tạp và tối ưu.
Câu hỏi đánh giá: "Giải thích thuật toán của em bằng lời — không dùng code. Với input này, thuật toán thực hiện bao nhiêu bước?"
Biểu hiện qua sản phẩm: Giả mã trong worksheet khớp với code thực tế; code không có bước dư thừa hoặc thiếu.
Công cụ đánh giá CT tổng hợp: Không có bài kiểm tra CT chuẩn. CT được đánh giá qua tổ hợp: worksheet (đặc biệt phần Mô hình hóa và Lập kế hoạch) + quan sát trong giờ + phỏng vấn ngắn sau hoạt động + phân tích chất lượng code. Trong đó phỏng vấn ngắn ("oral defense" 3–5 phút) là công cụ đánh giá CT hiệu quả nhất nhưng tốn thời gian nhất.
5.1.5. Đánh giá hợp tác (Collaboration Assessment)
Bản chất: Đánh giá hợp tác không phải là chấm điểm "ai làm nhiều hơn" mà là đánh giá chất lượng tương tác trong quá trình học tập cộng tác. Đây là chiều đánh giá đặc biệt quan trọng với hình thức Pair Programming và hoạt động nhóm GQVĐ.
Bốn khía cạnh hợp tác cần đánh giá:
Đóng góp cân bằng (Balanced contribution): Mỗi thành viên có đóng góp thực chất không? Trong Pair Programming, cả hai có thực sự luân phiên vai Driver-Navigator không? Không ai chiếm toàn bộ, không ai chỉ ngồi xem.
Chất lượng giao tiếp kỹ thuật (Technical communication): Học sinh có giải thích rõ ý tưởng cho bạn không? Có đặt câu hỏi thay vì chỉ nói đáp án không? Có lắng nghe và phản hồi ý kiến bạn không?
Giải quyết bất đồng (Conflict resolution): Khi có hai ý kiến khác nhau, nhóm xử lý thế nào? Có dùng bằng chứng kỹ thuật (chạy thử, phân tích độ phức tạp) để quyết định không? Hay bỏ phiếu hoặc ai mạnh hơn thắng?
Hỗ trợ đồng đẳng (Peer support): Học sinh giỏi có giải thích đủ kiên nhẫn cho bạn yếu hơn không? Học sinh yếu hơn có chủ động hỏi thay vì ngồi im không?
Lưu ý về đánh giá hợp tác: Đây là chiều đánh giá nhạy cảm nhất vì liên quan đến quan hệ xã hội trong lớp. Cần tránh tình huống đánh giá hợp tác làm học sinh "tố cáo" nhau hoặc gây ra xung đột. Self-assessment và peer assessment hợp tác cần có quy trình rõ ràng và văn hóa lớp học an toàn.
5.1.6. Đánh giá AI Literacy
Bản chất: AI Literacy trong bối cảnh Tin học phổ thông là khả năng học sinh hiểu, sử dụng, đánh giá và phản biện các công cụ AI tạo sinh một cách có ý thức và có trách nhiệm. Đây là chiều đánh giá mới nhất, chưa có nhiều tài liệu hướng dẫn cụ thể — nhưng ngày càng quan trọng.
Năm thành phần AI Literacy cần đánh giá:
Hiểu biết về cơ chế AI: Học sinh có hiểu AI hoạt động theo xác suất, không "biết" sự thật, có thể tạo ra thông tin sai (hallucination) không? Có hiểu tại sao cùng một prompt đôi khi cho kết quả khác nhau không?
Kỹ năng đặt prompt hiệu quả: Học sinh có thể đặt prompt rõ ràng, cụ thể, có ngữ cảnh đủ để AI hiểu đúng yêu cầu không? Có biết cách cải thiện prompt khi kết quả chưa như mong muốn không?
Tư duy phản biện về output AI: Học sinh có kiểm chứng kết quả AI không? Có phát hiện được lỗi trong code/nội dung do AI tạo ra không? Có đặt câu hỏi về giả định ẩn trong lời giải AI không?
Sử dụng AI có trách nhiệm: Học sinh có trung thực về việc dùng AI không? Có biết khi nào nên và không nên dùng AI không? Có tôn trọng bản quyền và quyền riêng tư khi dùng AI không?
Tích hợp AI có giá trị học tập: Học sinh dùng AI để học sâu hơn hay để tránh học? Có thể giải thích được tại sao chấp nhận hay bác bỏ một đề xuất của AI không?
________________________________________
5.2. Thiết kế công cụ đánh giá
5.2.1. Rubric
Bản chất: Rubric là bảng mô tả các mức độ thực hiện theo từng tiêu chí đánh giá. Rubric tốt phải đủ cụ thể để hai GV khác nhau đọc vào cùng cho điểm gần nhau (inter-rater reliability), đủ rõ để học sinh đọc vào biết mình cần làm gì để đạt từng mức.
Hai loại rubric:
Rubric toàn thể (Holistic rubric): Đánh giá tổng thể sản phẩm theo một thang điểm duy nhất. Nhanh nhưng ít thông tin phản hồi. Phù hợp khi cần đánh giá nhanh nhiều sản phẩm.
Rubric phân tích (Analytic rubric): Đánh giá theo từng tiêu chí riêng biệt, mỗi tiêu chí có thang điểm riêng. Tốn thời gian hơn nhưng cho phản hồi chi tiết. Phù hợp với đánh giá vì học tập.
Quy trình thiết kế rubric (5 bước):
Bước 1 — Xác định tiêu chí từ mục tiêu học tập: Mỗi tiêu chí trong rubric phải tương ứng với một mục tiêu học tập đã xác định ở Chương 3. Không được tự thêm tiêu chí không có trong mục tiêu — ví dụ không đánh giá "trình bày đẹp" nếu mục tiêu không bao gồm điều này.
Bước 2 — Xác định số mức: Thường 3–4 mức là phù hợp. 2 mức (đạt/không đạt) quá đơn giản; 5+ mức khó phân biệt nhất quán.
Bước 3 — Mô tả mức cao nhất trước: Viết mô tả cho mức xuất sắc — đây là hình ảnh của "thực hiện hoàn hảo theo mục tiêu". Tránh dùng từ mơ hồ ("tốt", "rõ ràng") mà mô tả bằng hành vi quan sát được.
Bước 4 — Mô tả mức thấp nhất: Mô tả "chưa đạt yêu cầu tối thiểu". Đây thường là mô tả sản phẩm/hành vi chỉ đạt được ở mức bề mặt.
Bước 5 — Điền các mức trung gian: Các mức ở giữa là các điểm trên đường từ "chưa đạt" đến "xuất sắc" — không phải đơn giản là "đạt một nửa" mà là mô tả trạng thái phát triển cụ thể.
Các lỗi thiết kế rubric phổ biến cần tránh:
Lỗi Ví dụ Cách sửa
Mô tả mơ hồ "Code viết tốt" "Tên biến phản ánh đúng ý nghĩa, có comment ở các hàm phức tạp"
Tiêu chí chồng chéo "Đúng" và "Chính xác" là hai tiêu chí riêng Gộp lại hoặc phân biệt rõ nghĩa
Dùng phủ định để mô tả "Không có lỗi" "Chạy đúng với tất cả test case..."
Không có bằng chứng quan sát được "Hiểu thuật toán tốt" "Giải thích được từng bước thuật toán bằng lời khi được hỏi"
Rubric mẫu toàn diện — Đánh giá hoạt động GQVĐ lập trình Python:
(Dùng cho bài tập Tầng 2, Tin học 10 — Kết nối tri thức)
Tiêu chí 4 — Xuất sắc 3 — Đạt 2 — Cần cải thiện 1 — Chưa đạt
Phân tích đề bài (Bước 1–2) Xác định đúng và đầy đủ input, output, ràng buộc; tự phát hiện ít nhất 2 edge case Xác định đúng input, output; xác định ràng buộc chính; phát hiện 1 edge case Xác định đúng input và output; bỏ sót ràng buộc quan trọng Không phân tích đề bài; nhảy thẳng vào code
Lập kế hoạch (Bước 3–4) Có giả mã/sơ đồ khối rõ ràng trước khi code; giả mã đủ chi tiết để cài đặt trực tiếp Có giả mã nhưng còn thiếu một số bước; cần suy nghĩ thêm khi code Có một vài ghi chú nhưng không đủ thành giả mã Không có kế hoạch; bắt đầu code ngay khi đọc xong đề
Tính đúng đắn (Bước 5–6) Đúng với tất cả test case kể cả edge case; xử lý đúng các trường hợp đặc biệt Đúng với test case thông thường; sai với 1–2 edge case Đúng với 50–70% test case; có lỗi logic rõ ràng Dưới 50% test case đúng; lỗi cơ bản chưa được sửa
Chất lượng code Tên biến/hàm rõ nghĩa; có comment ở chỗ phức tạp; cấu trúc logic, không dư thừa Tên biến chấp nhận được; cấu trúc đọc được; ít comment Một số tên biến khó hiểu; cấu trúc chưa rõ ràng Tên biến a, b, x; không có cấu trúc; không thể đọc
Kiểm thử (Bước 6) Bảng test case đầy đủ: ít nhất 5 test case, bao gồm 2+ edge case; tự thiết kế test case ngoài yêu cầu Bảng test case đủ 4 test case bao gồm 1 edge case Chỉ 2–3 test case thông thường; không có edge case Không có bảng test case; không kiểm thử
Phản tư (Bước 7–8) Phân tích cụ thể khó khăn gặp phải; rút ra bài học tổng quát có thể áp dụng bài khác; đặt câu hỏi mở rộng Phản tư đủ nhưng chung chung; có đề cập khó khăn Phản tư rất ngắn; không có bài học rút ra Bỏ trống phần phản tư
Tổng: 24 điểm → Quy về 10
5.2.2. Checklist
Bản chất và phân biệt với rubric: Checklist đơn giản hơn rubric — mỗi mục chỉ có hai trạng thái: có/không hoặc đạt/chưa đạt. Phù hợp với: (1) đánh giá sự hiện diện của các thành phần bắt buộc (checklist hoàn thành), (2) học sinh tự kiểm tra trước khi nộp (self-check), (3) đánh giá quá trình theo mốc thời gian (milestone checklist).
Điểm mạnh của checklist: nhanh, rõ ràng, học sinh dễ tự dùng. Điểm yếu: không phân biệt mức độ — chỉ biết "có" hay "không", không biết "tốt đến mức nào".
Ba loại checklist cần thiết kế:
Checklist tự kiểm tra trước nộp bài (Self-check before submission): Học sinh tự xác nhận đã hoàn thành đầy đủ trước khi nộp. Đặt ở cuối worksheet hoặc in thành phiếu riêng.
CHECKLIST TỰ KIỂM TRA — BÀI LẬP TRÌNH PYTHON
Phần phân tích:
[ ] Tôi đã xác định rõ input và output của bài toán.
[ ] Tôi đã liệt kê ít nhất 2 trường hợp đặc biệt cần xử lý.
Phần thiết kế:
[ ] Tôi đã viết giả mã/sơ đồ khối trước khi viết code.
[ ] Giả mã của tôi đủ chi tiết để cài đặt trực tiếp.
Phần code:
[ ] Code của tôi chạy không có lỗi cú pháp.
[ ] Tên biến và hàm phản ánh đúng ý nghĩa (không dùng a, b, x).
[ ] Có comment ở các đoạn logic phức tạp.
Phần kiểm thử:
[ ] Tôi đã chạy thử với ít nhất 5 test case khác nhau.
[ ] Tôi đã thử ít nhất 2 trường hợp đặc biệt (edge case).
[ ] Bảng test case trong worksheet đã được điền đầy đủ.
Phần phản tư:
[ ] Tôi đã điền đầy đủ phần phản tư trong worksheet.
[ ] Tôi đã ghi lại ít nhất 1 bài học tổng quát từ hoạt động này.
Tổng số ô được check: ___/13
Nếu dưới 10: Xem xét lại trước khi nộp.
Checklist quan sát của GV (Teacher observation checklist): GV dùng trong giờ thực hành để ghi nhận nhanh hành vi của từng học sinh.
CHECKLIST QUAN SÁT — TIẾT THỰC HÀNH
Học sinh: _________________ Bài tập: _________________
Quá trình:
[ ] Đọc đề trước khi bắt đầu code (> 2 phút đọc đề)
[ ] Có ghi chép/phân tích trước khi gõ code
[ ] Có viết giả mã hoặc sơ đồ
[ ] Chạy thử thường xuyên (không code > 10 dòng mà không test)
[ ] Đọc thông báo lỗi khi bị lỗi (không gọi GV ngay)
[ ] Tự debug trước khi nhờ hỗ trợ
Hành vi đặc biệt cần ghi nhận:
[ ] Sao chép code của bạn
[ ] Dùng AI để nhận code hoàn chỉnh
[ ] Dùng AI đúng cách (hỏi gợi ý, tự cài đặt)
[ ] Hoàn thành sớm và tự tìm thách thức tiếp theo
Ghi chú nhanh: ________________________________
Checklist milestone dự án (Project milestone checklist): Dùng trong PjBL để theo dõi tiến độ nhóm qua các mốc thời gian.
CHECKLIST MILESTONE — DỰ ÁN QUẢN LÝ THƯ VIỆN
Mốc 1 (Tuần 1):
[ ] Nhóm đã phỏng vấn ít nhất 2 "người dùng" để hiểu yêu cầu
[ ] Đã xác định rõ 5+ chức năng cần có
[ ] Đã phân công vai trò rõ ràng
Mốc 2 (Tuần 2):
[ ] Đã thiết kế schema CSDL (ít nhất 3 bảng, có khóa)
[ ] Schema đã được GV review và chấp thuận
[ ] Đã tạo được CSDL trên phần mềm
Mốc 3 (Tuần 3):
[ ] Chức năng thêm/xóa/sửa hoạt động đúng
[ ] Chức năng tìm kiếm hoạt động đúng
[ ] Đã kiểm thử với ít nhất 20 bản ghi dữ liệu mẫu
Mốc 4 (Tuần 4):
[ ] Demo sản phẩm cho "người dùng" thực tế (ít nhất 1 người)
[ ] Đã ghi nhận phản hồi và cải tiến ít nhất 2 điểm
[ ] Báo cáo dự án hoàn chỉnh
5.2.3. Portfolio học tập
Bản chất: Portfolio không phải là tập hợp ngẫu nhiên các bài làm của học sinh — đó là bộ sưu tập có chủ đích các bằng chứng học tập, được học sinh tự chọn và tự phản tư, phản ánh sự phát triển theo thời gian. Portfolio trả lời câu hỏi "Em đã học được gì và em biết mình đã học được gì" — không phải chỉ "Em làm được gì".
Sự khác biệt giữa portfolio và tập hồ sơ bài làm:
Portfolio học tập Tập hồ sơ bài làm
Học sinh tự chọn bằng chứng có chủ đích GV thu thập tất cả bài làm
Có phần phản tư giải thích tại sao chọn bằng chứng này Không có giải thích
Thể hiện sự phát triển theo thời gian Chỉ là snapshot tại một thời điểm
Học sinh là chủ thể GV là chủ thể
Cấu trúc portfolio học tập Tin học (theo học kỳ):
Phần 1 — Giới thiệu cá nhân (Introduction): Học sinh tự viết: Tôi là ai với tư cách người học Tin học? Tôi bắt đầu học kỳ này với những gì? Tôi muốn đạt được gì?
Phần 2 — Bằng chứng học tập đã chọn (Selected evidence): Học sinh chọn 3–5 bằng chứng từ các hoạt động trong học kỳ, mỗi bằng chứng kèm theo phần phản tư.
Các loại bằng chứng hợp lệ:
• Worksheet hoàn chỉnh của một hoạt động GQVĐ
• Code của một bài tập học sinh tự hào nhất
• Một bài tập làm sai và quá trình sửa lại
• Ghi chép nhật ký từ một tiết học đặc biệt
• Sản phẩm nhóm có ghi rõ đóng góp cá nhân
Mẫu phần phản tư cho mỗi bằng chứng:
Bằng chứng này là gì: ________________________________
Tôi chọn bằng chứng này vì: ________________________________
Bằng chứng này cho thấy tôi đã học được: ________________________________
Điều tôi sẽ làm khác nếu làm lại: ________________________________
Kỹ năng/tư duy nào từ đây tôi muốn phát triển tiếp: ________________________________
Phần 3 — Bằng chứng về sự phát triển (Growth evidence): So sánh một bài làm đầu học kỳ với một bài làm cuối học kỳ — chỉ ra cụ thể sự khác biệt và giải thích điều gì dẫn đến sự thay đổi đó.
Phần 4 — Tự đánh giá tổng thể (Self-assessment): Học sinh đánh giá bản thân theo từng mục tiêu học tập của học phần — không phải điểm số mà là mô tả bằng chứng cụ thể cho từng mục tiêu.
Phần 5 — Kế hoạch tiếp theo (Forward-looking goals): Tôi sẽ tiếp tục phát triển điều gì trong thời gian tới? Cụ thể là gì?
Hướng dẫn triển khai portfolio trong thực tế:
Portfolio hiệu quả cần được xây dựng dần từng tuần, không thể làm dồn vào cuối kỳ. GV cần dành 5–10 phút cuối mỗi 2–3 tiết để học sinh cập nhật portfolio. Công cụ số phù hợp: Google Sites, Notion, hoặc đơn giản là Google Drive có cấu trúc thư mục.
5.2.4. Nhật ký học tập (Learning Journal)
Bản chất: Nhật ký học tập là ghi chép định kỳ (sau mỗi tiết hoặc sau mỗi hoạt động lớn) của học sinh về quá trình học tập của mình — không phải ghi lại nội dung bài học mà ghi lại trải nghiệm học tập: tôi hiểu gì, tôi chưa hiểu gì, tôi cảm thấy gì, tôi đã làm gì để vượt qua khó khăn.
Nhật ký học tập khác gì phần phản tư trong worksheet: Worksheet phản tư tập trung vào một hoạt động cụ thể. Nhật ký học tập có tầm nhìn rộng hơn — học sinh nhìn lại tiến trình học tập qua nhiều hoạt động, nhận ra pattern trong cách mình học, và đặt mục tiêu cho lần học tiếp theo.
Ba dạng nhật ký học tập trong Tin học:
Nhật ký kỹ thuật (Technical journal): Tập trung vào nội dung kỹ thuật — những lỗi đã gặp và cách sửa, những pattern lập trình đã học, những kỹ thuật mới khám phá. Hữu ích như tài liệu tra cứu cá nhân.
Nhật ký quá trình (Process journal): Tập trung vào cách học sinh tiếp cận bài toán — chiến lược nào hiệu quả, bước nào hay bị bỏ qua, thói quen nào cần cải thiện. Hữu ích để phát triển metacognition.
Nhật ký phản tư (Reflective journal): Tập trung vào cảm xúc và ý nghĩa — tôi cảm thấy thế nào khi debug thành công, tôi học được gì về bản thân mình qua hoạt động này, điều gì tạo ra động lực học tập của tôi. Hữu ích để phát triển growth mindset.
Cấu trúc nhật ký học tập đơn giản (dùng sau mỗi tiết thực hành):
NHẬT KÝ HỌC TẬP — TIẾT [số] — NGÀY ___/___/___
1. Ba điều tôi làm được hôm nay:
•
•
•
2. Một điều tôi gặp khó khăn và đã làm gì để vượt qua:
3. Một điều tôi vẫn chưa rõ sau tiết hôm nay:
4. Một câu hỏi tôi muốn tìm hiểu thêm:
5. Mục tiêu của tôi cho tiết học tới:
Câu hỏi nhật ký chuyên sâu hơn (dùng sau hoạt động lớn):
NHẬT KÝ PHẢN TƯ SAU HOẠT ĐỘNG GQVĐ
1. Mô tả ngắn gọn hoạt động bạn vừa hoàn thành:
2. Bước nào trong quy trình GQVĐ bạn thực hiện tốt nhất?
Bằng chứng cụ thể là gì?
3. Bước nào bạn còn yếu? Điều gì cụ thể đã xảy ra?
4. Khi gặp khó khăn, bạn đã làm gì đầu tiên? Điều đó có hiệu quả không?
5. Bạn đã sử dụng AI trong hoạt động này chưa? Nếu có:
- Hỏi AI điều gì?
- AI trả lời có đúng không? Bạn kiểm chứng thế nào?
- Bạn học được gì từ tương tác với AI?
6. So với hoạt động GQVĐ trước đó, bạn thấy mình tiến bộ ở điểm nào?
Còn điểm nào chưa thay đổi?
7. Điều bạn muốn làm khác đi trong hoạt động GQVĐ tiếp theo là gì?
5.2.5. AI Log
Bản chất và lý do cần thiết: AI Log là công cụ đánh giá hoàn toàn mới, chưa có trong các tài liệu đánh giá truyền thống. Khi học sinh sử dụng AI trong quá trình học, AI Log ghi lại toàn bộ tương tác giữa học sinh và AI — prompt đã dùng, kết quả nhận được, đánh giá của học sinh về kết quả đó, và quyết định cuối cùng của học sinh. AI Log biến "hộp đen" (học sinh dùng AI thế nào) thành bằng chứng học tập có thể đánh giá.
Năm chức năng của AI Log:
Minh bạch hóa quá trình sử dụng AI: GV biết học sinh dùng AI ở bước nào, hỏi gì, nhận được gì — không phải để "bắt lỗi" mà để hiểu học sinh đang ở đâu trong quá trình học tập.
Đánh giá chất lượng prompt: Prompt học sinh đặt ra phản ánh mức độ hiểu bài toán — prompt tốt chứng minh học sinh đã phân tích đề tốt.
Đánh giá tư duy phản biện về AI: Học sinh có đánh giá kết quả AI không? Có kiểm chứng không? Có phát hiện lỗi không?
Đánh giá tích hợp AI có giá trị học tập: AI Log phân biệt học sinh dùng AI để học sâu hơn với học sinh dùng AI để tránh học.
Nguồn dữ liệu cho GV cải thiện thiết kế: Nếu nhiều học sinh hỏi AI cùng một câu hỏi, đó là tín hiệu scaffold ở điểm đó chưa đủ.
Cấu trúc AI Log hoàn chỉnh:
AI LOG — [Tên học sinh] — [Tên bài tập] — [Ngày]
═══ TƯƠNG TÁC 1 ═══
Thời điểm: [Bước GQVĐ nào? VD: Bước 2 — Phân tích]
Trước khi hỏi AI, tôi đã tự làm/nghĩ:
_________________________________________________
Prompt tôi đã dùng:
_________________________________________________
Kết quả AI trả lời (tóm tắt hoặc dán nguyên):
_________________________________________________
Đánh giá của tôi về kết quả này:
[ ] Đúng và hữu ích — tôi dùng nguyên
[ ] Đúng một phần — tôi dùng có chỉnh sửa
[ ] Chưa chắc đúng — tôi cần kiểm chứng thêm
[ ] Sai — tôi không dùng
Nếu có sai sót, tôi phát hiện được điều gì:
_________________________________________________
Quyết định cuối cùng của tôi (tôi đã làm gì sau khi nhận kết quả AI):
_________________________________________________
Tôi học được gì từ tương tác này:
_________________________________________________
══════════════════
[Lặp lại cho mỗi tương tác với AI]
═══ TỔNG KẾT ═══
Tổng số lần tương tác với AI trong bài này: ___
Bước GQVĐ nào tôi dùng AI nhiều nhất: ___________
Lý do: ___________________________________________
Nhìn lại, tôi nghĩ việc dùng AI đã giúp tôi:
_________________________________________________
Nhìn lại, tôi nghĩ mình nên làm khác đi:
_________________________________________________
________________________________________
5.3. Đánh giá trong bối cảnh AI
5.3.1. Đánh giá prompt
Bản chất: Đánh giá prompt là đánh giá khả năng học sinh giao tiếp với AI một cách hiệu quả và có chủ đích. Đây là kỹ năng ngày càng quan trọng — "prompt literacy" là thành phần cốt lõi của AI Literacy.
Rubric đánh giá chất lượng prompt:
Tiêu chí 4 — Xuất sắc 3 — Đạt 2 — Cần cải thiện 1 — Chưa đạt
Tính cụ thể Prompt cung cấp đầy đủ ngữ cảnh: bối cảnh bài toán, trình độ người hỏi, định dạng mong muốn của kết quả Có ngữ cảnh bài toán nhưng thiếu thông tin về trình độ hoặc định dạng Prompt có nội dung nhưng thiếu ngữ cảnh Prompt quá ngắn hoặc mơ hồ
Định hướng học tập Hỏi để hiểu hơn (gợi ý hướng đi, giải thích khái niệm) — không yêu cầu đáp án Hỏi gợi ý và có kèm yêu cầu giải thích Yêu cầu đáp án nhưng có kèm "giải thích" Yêu cầu đáp án hoàn chỉnh ngay lập tức
Phản ánh tư duy của học sinh Prompt cho thấy học sinh đã tự suy nghĩ trước ("Tôi đang nghĩ X nhưng chưa chắc về Y...") Có một ít bối cảnh về suy nghĩ của học sinh Hỏi câu hỏi mà không cho thấy đã tự suy nghĩ gì Prompt "sao chép" y nguyên đề bài cho AI
Cải thiện prompt Khi kết quả chưa đúng ý, học sinh chỉnh sửa prompt có hệ thống dựa trên phân tích kết quả trước Có chỉnh sửa prompt khi cần nhưng chưa có phương pháp Thử lại với prompt gần như giống hệt Không cải thiện prompt
Bài tập đánh giá prompt — "Thiết kế prompt tốt nhất":
GV cho học sinh cùng một bài toán lập trình và yêu cầu thiết kế prompt để hỏi AI — không hỏi AI ngay. Học sinh nộp prompt thiết kế. GV chấm theo rubric trên. Sau đó học sinh dùng prompt đó hỏi AI và đánh giá kết quả có phản ánh chất lượng prompt không.
5.3.2. Đánh giá khả năng phản biện AI
Bản chất: Đánh giá xem học sinh có tư duy độc lập và có thể phát hiện sai sót trong output của AI không — đây là kỹ năng bảo vệ học sinh khỏi phụ thuộc mù quáng vào AI.
Hoạt động đánh giá "Tìm lỗi trong code AI":
GV chuẩn bị 3 đoạn code do AI tạo ra: một đoạn đúng hoàn toàn, một đoạn có lỗi logic nhỏ, một đoạn có lỗi logic nghiêm trọng. Học sinh nhiệm vụ:
1. Đọc và mô tả code làm gì (không chạy).
2. Dự đoán kết quả với 3 test case cụ thể.
3. Chạy thử và so sánh với dự đoán.
4. Xác định đoạn code nào có lỗi và mô tả lỗi đó.
5. Giải thích tại sao AI có thể tạo ra lỗi như vậy.
Rubric đánh giá khả năng phản biện AI:
Mức Mô tả
4 Phát hiện được cả lỗi tinh tế và lỗi nghiêm trọng; giải thích đúng nguyên nhân; đề xuất được cách sửa; nhận xét về pattern lỗi của AI
3 Phát hiện được lỗi nghiêm trọng; giải thích được nguyên nhân; đề xuất cách sửa
2 Phát hiện được lỗi nghiêm trọng nhưng giải thích nguyên nhân chưa đúng hoặc không đề xuất được cách sửa
1 Không phát hiện được lỗi, hoặc phát hiện nhưng không giải thích được
5.3.3. Đánh giá quá trình chỉnh sửa lời giải AI
Bản chất: Đánh giá xem học sinh có cải thiện được lời giải AI không — không phải sao chép nguyên mà hiểu đủ để nâng chất lượng lên.
Hoạt động đánh giá "Cải thiện code AI":
Học sinh nhận một đoạn code đúng do AI tạo ra nhưng có một trong các vấn đề sau: không xử lý edge case, tên biến khó đọc, không có comment, không tối ưu. Học sinh nhiệm vụ: chạy thử và xác nhận code đúng, sau đó tự cải thiện theo tiêu chí được cho và giải thích từng thay đổi.
Rubric đánh giá cải thiện code AI:
Tiêu chí 4 3 2 1
Xác định điểm cần cải thiện Phát hiện ≥ 3 điểm cần cải thiện với lý do kỹ thuật rõ ràng Phát hiện 2 điểm với lý do Phát hiện 1 điểm Không phát hiện được hoặc chỉ nhận xét chung chung
Chất lượng cải thiện Mọi thay đổi đều có căn cứ kỹ thuật; không làm hỏng tính đúng đắn của code Hầu hết thay đổi có căn cứ; code vẫn đúng Một số thay đổi có căn cứ; một vài thay đổi làm hỏng code Thay đổi tùy tiện hoặc làm code hỏng
Giải thích thay đổi Giải thích chi tiết từng thay đổi bằng lý do kỹ thuật Giải thích đủ nhưng một số còn chung chung Giải thích sơ sài Không giải thích
5.3.4. Đánh giá mức độ sử dụng AI có trách nhiệm
Bản chất: Đây là chiều đánh giá phức tạp nhất — liên quan đến giá trị và thái độ, không chỉ kỹ năng. Không thể đánh giá qua bài kiểm tra mà chủ yếu qua AI Log, quan sát và phỏng vấn.
Khung đánh giá AI Responsible Use — 4 mức:
Mức 4 — Sử dụng AI có ý thức và có chiến lược: Học sinh có chính sách cá nhân rõ ràng về khi nào dùng và không dùng AI; ghi chép AI Log đầy đủ và phản tư sâu; chủ động kiểm chứng output AI; hiểu và tôn trọng các giới hạn về học thuật.
Mức 3 — Sử dụng AI phù hợp theo hướng dẫn: Học sinh tuân theo hướng dẫn của GV về sử dụng AI; ghi AI Log đủ; kiểm chứng output AI khi được nhắc.
Mức 2 — Sử dụng AI không nhất quán: Đôi khi dùng AI đúng cách, đôi khi lạm dụng; ghi AI Log thiếu sót; ít khi tự kiểm chứng.
Mức 1 — Sử dụng AI không có trách nhiệm: Dùng AI để nhận sản phẩm hoàn chỉnh mà không học tập; không ghi AI Log; không kiểm chứng; không trung thực về việc dùng AI.
Câu hỏi phỏng vấn đánh giá AI Literacy (dùng trong oral defense):
• "Em đã dùng AI trong bài này không? Ở bước nào và để làm gì?"
• "Kết quả AI trả lời lần đó có đúng hoàn toàn không? Em biết điều đó bằng cách nào?"
• "Có lần nào AI đề xuất điều gì đó và em quyết định không làm theo không? Vì sao?"
• "Em nghĩ kỹ năng nào trong bài này em sẽ không phát triển được nếu cứ để AI làm thay?"
________________________________________
5.4. Hệ thống đánh giá tổng hợp — Kết nối 6 chiều và 5 công cụ
Thực tế thiết kế đánh giá không phải là "dùng tất cả 5 công cụ cho tất cả 6 chiều" — điều đó vừa không khả thi vừa không cần thiết. GV cần chọn lựa có chiến lược dựa trên:
Ma trận lựa chọn công cụ theo chiều đánh giá:
Chiều đánh giá Rubric Checklist Portfolio Nhật ký AI Log
Quá trình ✓✓ ✓ ✓ ✓✓ ✓
Sản phẩm ✓✓ ✓✓ ✓ — —
Chiến lược GQVĐ ✓ — ✓✓ ✓✓ —
Tư duy tính toán ✓ — ✓✓ ✓ —
Hợp tác ✓ ✓ ✓ ✓ —
AI Literacy ✓ ✓ ✓ ✓ ✓✓
✓✓ = công cụ phù hợp nhất; ✓ = có thể dùng; — = ít phù hợp
Nguyên tắc thiết kế hệ thống đánh giá:
Nguyên tắc 1 — Đủ bằng chứng, không quá tải: Mỗi hoạt động GQVĐ cần ít nhất 2–3 nguồn bằng chứng để đánh giá đáng tin cậy, nhưng không nên quá 4–5 — học sinh sẽ bị áp lực bởi công cụ đánh giá thay vì tập trung vào học tập.
Nguyên tắc 2 — Đánh giá phục vụ học tập, không phải ngược lại: Nếu thiết kế công cụ đánh giá làm học sinh mất thời gian học tập thực sự, đó là thiết kế sai. Worksheet, AI Log, nhật ký đều phải có giá trị như công cụ học tập độc lập với chức năng đánh giá.
Nguyên tắc 3 — Học sinh biết trước tiêu chí: Rubric và checklist cần được chia sẻ với học sinh trước khi bắt đầu hoạt động — không phải sau khi nộp. Học sinh cần biết mình sẽ được đánh giá theo gì để định hướng nỗ lực.
Nguyên tắc 4 — Cân bằng giữa đánh giá GV, tự đánh giá và đánh giá đồng đẳng: Không nên để GV là người đánh giá duy nhất — điều đó tạo phụ thuộc và giảm phát triển metacognition. Self-assessment và peer assessment cần được tích hợp có cấu trúc.
________________________________________
E. THỰC HÀNH (3 tiết) — THIẾT KẾ BỘ CÔNG CỤ ĐÁNH GIÁ HOÀN CHỈNH
Mục tiêu thực hành
Mỗi nhóm sinh viên thiết kế một bộ công cụ đánh giá đầy đủ cho một hoạt động GQVĐ cụ thể — có thể là hoạt động đã thiết kế ở Chương 3 (tạo sự liên thông) hoặc một hoạt động mới.
________________________________________
Mẫu bộ công cụ đánh giá hoàn chỉnh — Ví dụ tham chiếu
Hoạt động GQVĐ: Kiểm tra số nguyên tố (Tin học 10, Kết nối tri thức) — tiếp nối từ ví dụ mẫu Chương 3.
________________________________________
CÔNG CỤ 1: RUBRIC TỔNG THỂ
(Đánh giá cuối hoạt động — GV chấm)
Tiêu chí Trọng số 4 — Xuất sắc 3 — Đạt 2 — Cần cải thiện 1 — Chưa đạt
Phân tích đề và lập kế hoạch 20% Phân tích đủ input/output/edge case; có giả mã chi tiết và đúng hướng Phân tích đủ input/output; giả mã có nhưng còn thiếu Phân tích sơ lược; không có giả mã thực sự Không phân tích; không có giả mã
Tính đúng đắn của code 30% Đúng tất cả 7 test case kể cả n=0, n=1, n=2, n=-5 Đúng 5–6/7 test case Đúng 3–4/7 test case Đúng ≤2/7 test case
Chất lượng kỹ thuật 15% Tên biến rõ nghĩa; có comment logic phức tạp; cấu trúc hàm hợp lý Tên biến chấp nhận được; cấu trúc đọc được Tên biến khó hiểu; thiếu comment Không có cấu trúc; không đọc được
Kiểm thử 20% ≥5 test case; ≥2 edge case tự thiết kế; có cột kết quả thực tế 4 test case; 1 edge case 2–3 test case thông thường 0–1 test case
Tư duy tính toán 15% Giải thích được thuật toán + tại sao chỉ cần kiểm tra đến √n + phân rã vấn đề rõ Giải thích được thuật toán; chưa giải thích được tối ưu √n Giải thích được một phần Không giải thích được
Tính điểm: (Điểm từng tiêu chí × Trọng số) × 10/4
________________________________________
CÔNG CỤ 2: CHECKLIST TỰ KIỂM TRA
(Học sinh dùng trước khi nộp — 5 phút)
CHECKLIST TỰ KIỂM TRA — BÀI KIỂM TRA SỐ NGUYÊN TỐ
Phân tích đề:
[ ] Tôi đã xác định: input là số nguyên n, output là chuỗi "nguyên tố"
hoặc "không nguyên tố"
[ ] Tôi đã liệt kê các trường hợp đặc biệt: n<2, n=2, số âm
Lập kế hoạch:
[ ] Tôi đã viết giả mã trước khi viết code
[ ] Giả mã của tôi xử lý đủ cả 3 giai đoạn: kiểm tra n<2, vòng lặp
tìm ước, in kết quả
Code:
[ ] Code chạy không có lỗi cú pháp
[ ] Tên biến rõ nghĩa (không dùng a, b, x)
[ ] Có comment giải thích vòng lặp và điều kiện dừng
Kiểm thử (điền vào bảng worksheet):
[ ] n = 2 → "2 là số nguyên tố" ✓/✗ Kết quả thực tế: ___
[ ] n = 1 → "1 không phải số nguyên tố" ✓/✗ Kết quả thực tế: ___
[ ] n = 0 → xử lý đúng ✓/✗ Kết quả thực tế: ___
[ ] n = -5 → xử lý đúng ✓/✗ Kết quả thực tế: ___
[ ] n = 17 → "17 là số nguyên tố" ✓/✗ Kết quả thực tế: ___
[ ] n = 15 → "15 không phải số nguyên tố" ✓/✗ Kết quả thực tế: ___
[ ] n = 97 → "97 là số nguyên tố" ✓/✗ Kết quả thực tế: ___
[ ] Test case tự thêm: n = ___ → ___ ✓/✗ Kết quả thực tế: ___
Phản tư:
[ ] Tôi đã điền đầy đủ phần phản tư trong worksheet
[ ] Tôi đã ghi lại ít nhất 1 bài học có thể dùng cho bài khác
Tổng ô đã check: ___/16
________________________________________
CÔNG CỤ 3: AI LOG
(Học sinh điền trong và sau hoạt động)
AI LOG — BÀI: KIỂM TRA SỐ NGUYÊN TỐ
Tên học sinh: _______________
TT1 | Thời điểm: Bước ___ [Đọc đề / Phân tích / Lập kế hoạch /
Thực hiện / Kiểm tra / Đánh giá]
Trước khi hỏi AI, tôi đã tự nghĩ:
_________________________________________________
Prompt tôi đã dùng:
_________________________________________________
AI trả lời (tóm tắt):
_________________________________________________
Đánh giá của tôi:
○ Đúng và hữu ích ○ Đúng, có chỉnh sửa ○ Cần kiểm chứng ○ Sai
Tôi đã làm gì sau đó:
_________________________________________________
Bài học từ tương tác này:
_________________________________________________
─────────────────────────────
[TT2, TT3... nếu có]
TỔNG KẾT:
Tổng số lần hỏi AI: ___
Bước hỏi nhiều nhất: ___
Lần nào có ích nhất và tại sao: ___________________________
Lần nào ít có ích nhất và tại sao: _________________________
Nếu làm bài tương tự, tôi sẽ dùng AI khác đi thế nào: _______
________________________________________
CÔNG CỤ 4: NHẬT KÝ HỌC TẬP SAU HOẠT ĐỘNG
(Học sinh điền sau khi nộp bài — 5–7 phút)
NHẬT KÝ HỌC TẬP — SAU BÀI KIỂM TRA SỐ NGUYÊN TỐ
Ngày: ___ Tên: _______________
1. Bước nào trong quy trình GQVĐ hôm nay tôi làm tốt nhất?
Bằng chứng cụ thể:
_________________________________________________
2. Bước nào tôi gặp khó nhất? Điều gì cụ thể đã xảy ra?
_________________________________________________
3. Khó khăn đó tôi đã vượt qua bằng cách nào?
○ Tự nghĩ ra ○ Hỏi bạn ○ Hỏi GV ○ Hỏi AI ○ Chưa vượt qua
Mô tả cụ thể:
_________________________________________________
4. Bài học tổng quát nhất tôi rút ra từ bài này
(không phải về số nguyên tố — mà về cách GQVĐ):
_________________________________________________
5. Pattern nào trong bài này tôi sẽ dùng được ở bài toán khác?
_________________________________________________
6. So với bài lập trình trước đó, tôi thấy mình:
○ Tiến bộ rõ ở: ___________________________________
○ Vẫn còn yếu ở: __________________________________
7. Mục tiêu cụ thể của tôi cho bài thực hành tiếp theo:
_________________________________________________
________________________________________
CÔNG CỤ 5: PHIẾU PEER REVIEW
(Học sinh đánh giá lẫn nhau — sau khi cả hai nộp bài)
PHIẾU PEER REVIEW — BÀI KIỂM TRA SỐ NGUYÊN TỐ
Người review: _____________ Code của: _____________ Ngày: ___
BƯỚC 1 — ĐỌC CODE (không chạy, 3 phút)
Code này làm gì? Mô tả bằng lời:
_________________________________________________
BƯỚC 2 — CHẠY THỬ (tự thiết kế test case)
Test case tôi tự thêm Kết quả mong đợi Kết quả thực tế Đúng?
n = .............. ☐
n = .............. ☐
n = .............. ☐
________________________________________
BƯỚC 3 — ĐIỀN PHIẾU REVIEW
Tiêu chí Nhận xét cụ thể Đề xuất cải thiện
Xử lý trường hợp n < 2
Logic vòng lặp tìm ước
Tên biến/hàm có rõ nghĩa không?
Có comment ở chỗ phức tạp không?
Test case có bao phủ đủ không?
________________________________________
ĐIỀU TÔI HỌC ĐƯỢC từ code của bạn:
..............................................................................................................
..............................................................................................................
________________________________________
MỘT CÂU HỎI tôi muốn hỏi tác giả:
..............................................................................................................
..............................................................................................................
NHẬN XÉT TỔNG THỂ (1–2 câu):
_________________________________________________
________________________________________
CÔNG CỤ 6: RUBRIC ĐÁNH GIÁ AI LITERACY
(GV chấm dựa trên AI Log + phỏng vấn ngắn nếu cần)
Tiêu chí 4 3 2 1
Chất lượng prompt Prompt cụ thể, có ngữ cảnh, định hướng học tập (không yêu cầu đáp án) Prompt đủ ngữ cảnh; yêu cầu gợi ý thay đáp án hoàn toàn Prompt thiếu ngữ cảnh; yêu cầu đáp án nhưng kèm "giải thích" Prompt là sao chép đề bài
Kiểm chứng output AI Tự thiết kế test case để kiểm tra; phát hiện được điểm chưa đúng nếu có Chạy test case cho sẵn để kiểm tra Chạy một lần và chấp nhận kết quả Không kiểm chứng
Tích hợp có giá trị học tập Dùng AI để gợi ý hướng suy nghĩ, tự cài đặt; AI Log cho thấy học được điều mới Dùng AI hỗ trợ một phần; tự làm phần còn lại Dùng AI ở bước lẽ ra cần tự làm; ít bằng chứng học tập Nhận code hoàn chỉnh từ AI; không học được gì
Trung thực và trách nhiệm AI Log đầy đủ, trung thực; phản tư chân thực về ưu nhược của việc dùng AI AI Log đủ; trung thực AI Log thiếu sót hoặc mơ hồ Không có AI Log; không trung thực về việc dùng AI
________________________________________
Tiến trình thực hành 3 tiết
Tiết thực hành 1: Phân tích mẫu và xây dựng khung đánh giá
Hoạt động 1 — Phân tích bộ công cụ mẫu (20 phút):
Sinh viên nhận bộ công cụ mẫu trên và thực hiện:
• Xác định mỗi công cụ đánh giá chiều nào trong 6 chiều (mục 5.1).
• Nhận xét: công cụ nào còn chưa rõ hoặc khó áp dụng?
• Đề xuất cải thiện ít nhất 1 công cụ.
Hoạt động 2 — Chọn hoạt động và xác định chiều đánh giá (25 phút):
Mỗi nhóm 2–3 sinh viên chọn hoạt động GQVĐ sẽ thiết kế bộ công cụ đánh giá (ưu tiên dùng hoạt động đã thiết kế ở Chương 3). Thực hiện:
• Liệt kê mục tiêu học tập của hoạt động đó.
• Quyết định đánh giá theo chiều nào (chọn ít nhất 4 trong 6 chiều, giải thích tại sao bỏ chiều nào).
• Quyết định dùng công cụ nào cho chiều nào.
• Lập bảng kế hoạch: ai dùng công cụ gì, khi nào, để đánh giá gì.
Tiết thực hành 2: Thiết kế công cụ đánh giá
Nhóm thiết kế đầy đủ ít nhất 4 công cụ trong số: rubric tổng thể, checklist tự kiểm tra, AI Log, nhật ký học tập, phiếu peer review, rubric AI Literacy. Mỗi công cụ cần đủ chi tiết để học sinh THPT có thể dùng ngay mà không cần giải thích thêm.
Tiêu chí kiểm tra chất lượng công cụ (dùng trước khi hoàn thiện):
• Rubric: mô tả bằng hành vi quan sát được, không mơ hồ.
• Checklist: mỗi mục có thể trả lời Có/Không rõ ràng.
• AI Log: đủ để biết học sinh dùng AI như thế nào mà không cần phỏng vấn.
• Nhật ký: câu hỏi mở nhưng có đủ định hướng để học sinh không viết lan man.
Tiết thực hành 3: Trình bày, phản biện và hoàn thiện
Trình bày (30 phút): Mỗi nhóm trình bày bộ công cụ trong 8 phút. Các nhóm khác đóng vai học sinh — đọc thử một công cụ và nhận xét: "Nếu em là học sinh lớp 10, em có hiểu phải làm gì không?"
Phản biện theo chuẩn (15 phút): Phản biện tập trung vào 3 câu hỏi:
1. Công cụ này đánh giá đúng chiều đã công bố không?
2. Tiêu chí có đủ cụ thể để hai người chấm cho điểm gần nhau không?
3. Công cụ này có giá trị học tập độc lập với chức năng đánh giá không?
Hoàn thiện (10 phút): Mỗi nhóm chỉnh sửa dựa trên phản biện và nộp bộ công cụ hoàn chỉnh.
________________________________________
F. RUBRIC ĐÁNH GIÁ BỘ CÔNG CỤ ĐÁNH GIÁ CỦA SINH VIÊN
Tiêu chí Tốt (3đ) Đạt (2đ) Chưa đạt (1đ)
Phủ đủ chiều đánh giá ≥4 chiều được đánh giá; mỗi chiều có ít nhất 1 công cụ phù hợp; có giải thích vì sao chọn/bỏ 4 chiều; một số công cụ chưa phù hợp nhất <4 chiều hoặc không giải thích lựa chọn
Chất lượng rubric Tiêu chí đo được; mô tả bằng hành vi quan sát; các mức phân biệt rõ; không có từ mơ hồ Tiêu chí đo được nhưng một số mô tả còn mơ hồ Tiêu chí chung chung; mức khó phân biệt
Checklist thực dụng Mỗi mục trả lời được Có/Không rõ ràng; đủ ngắn để dùng thực tế (<15 mục); bao phủ điểm quan trọng Hầu hết mục rõ ràng; độ dài hợp lý Nhiều mục mơ hồ hoặc quá dài
AI Log có giá trị Cấu trúc đủ để đánh giá AI Literacy; không quá dài làm học sinh né tránh; câu hỏi phản tư sâu Cấu trúc đủ; một số phần có thể rút gọn AI Log quá sơ sài hoặc quá dài
Nhật ký kích thích phản tư Câu hỏi mở nhưng có định hướng; kết nối quá trình và mục tiêu học tập; học sinh biết viết gì Câu hỏi đủ định hướng; chưa kết nối sâu Câu hỏi quá chung hoặc quá cụ thể
Tính nhất quán Tất cả công cụ nhất quán với mục tiêu học tập của hoạt động GQVĐ đã chọn; có thể dùng cùng nhau Nhất quán phần lớn; một vài công cụ chưa khớp Công cụ thiếu liên kết với mục tiêu hoặc với nhau
Tính khả thi Bộ công cụ có thể dùng trong một tiết học thực tế; không tạo gánh nặng quá mức cho học sinh Phần lớn khả thi; một vài công cụ cần rút gọn Bộ công cụ quá nặng để dùng thực tế
Tổng: 21 điểm → Quy về 10
________________________________________
G. KẾT NỐI VỚI CHƯƠNG 6 (Tích hợp AI toàn diện)
Chương 5 đã giới thiệu AI Log và các công cụ đánh giá AI Literacy như những thành phần riêng lẻ. Chương 6 sẽ đặt toàn bộ vòng đời dạy học GQVĐ — từ thiết kế (Ch.3), tổ chức (Ch.4), đến đánh giá (Ch.5) — vào trong bối cảnh tích hợp AI toàn diện và có trách nhiệm. Bộ công cụ đánh giá sinh viên thiết kế ở Chương 5 sẽ được đặt vào bối cảnh đó và xem xét liệu có cần bổ sung thêm không.
________________________________________
H. TÀI LIỆU THAM KHẢO
• Bộ GD&ĐT (2018). Chương trình giáo dục phổ thông môn Tin học (Thông tư 32/2018/TT-BGDĐT).
• Black, P., & Wiliam, D. (1998). Assessment and classroom learning. Assessment in Education, 5(1), 7–74.
• Wiggins, G., & McTighe, J. (2005). Understanding by Design (2nd ed.). ASCD.
• Anderson, L. W., & Krathwohl, D. R. (2001). A Taxonomy for Learning, Teaching, and Assessing. Longman.
• Bransford, J. D., Brown, A. L., & Cocking, R. R. (Eds.) (2000). How People Learn. National Academy Press.
• Wing, J. M. (2006). Computational thinking. Communications of the ACM, 49(3), 33–35.
• Long, D., & Magerko, B. (2020). What is AI literacy? Competencies and design considerations. CHI 2020.
• Carnevale, D. (2023). AI Literacy in K–12 and Higher Education. EDUCAUSE.
• UNESCO (2023). Guidance for generative AI in education and research.
• Hoàng Lê Minh (Tổng chủ biên) (2023). Tin học 10 — Kết nối tri thức với cuộc sống. NXB Giáo dục Việt Nam.
Nhận xét
Đăng nhận xét