Ở INFO5990 Professional Practice in IT, một bài làm đúng vẫn có thể bị điểm thấp, vì môn này chấm cách bạn lập luận để đi tới phán đoán chứ không chấm đáp án. Bài viết này giúp bạn hiểu người chấm thật sự tìm gì, viết phần đạo đức nghề nghiệp sao cho không dừng ở mức gọi tên vấn đề, chọn nguồn đủ sức làm bằng chứng, và trình bày cho người đọc ngoài ngành IT. Phần lớn sinh viên bước vào INFO5990 đã quen nhiều năm với những môn có đáp án rõ ràng, nơi đoạn mã chạy được hoặc không, phép chứng minh khép lại được hoặc không. Môn này gỡ bỏ chỗ dựa đó, và yêu cầu bạn phân tích các tình huống lưỡng nan đạo đức, đánh giá tác động của công nghệ thông tin, rồi trình bày hiệu quả bằng cả văn viết lẫn lời nói. Winner (1980) từng nói điều tương tự về công nghệ nói chung, rằng một lựa chọn kỹ thuật không bao giờ trung lập, và đó chính là bước đánh giá mà chuẩn đầu ra LO2 của môn đang đòi hỏi.
Tác giả: Ban Biên tập MAAS · Hiệu đính bởi một mentor chuyên môn của MAAS
Cập nhật: 18/08/2026
Chuyên mục: it-data
Môn INFO5990 là gì, và ai đang ngồi cạnh bạn?
Trả lời trực tiếp: INFO5990 Professional Practice in IT là môn sau đại học 6 tín chỉ (credit points) của University of Sydney, do School of Computer Science thuộc Faculty of Engineering giảng dạy, không có môn tiên quyết hay môn song hành bắt buộc. Trang môn học ghi INFO1111 và OINF5990 là hai môn xung khắc, vì tiền tố O đánh dấu bản học trực tuyến của cùng một môn.
Trang môn học của Sydney mô tả INFO5990 là môn giới thiệu các khái niệm, chuẩn mực và kỹ thuật gắn với thực hành nghề nghiệp công nghệ thông tin hiện nay trong môi trường doanh nghiệp. Trang ghi hai môn xung khắc là INFO1111 và OINF5990, liệt kê hai đợt mở lớp ở Semester 1 và Semester 2 năm 2026 theo hình thức học buổi tối tại hai cơ sở Camperdown và Darlington ở New South Wales, và nêu kiến thức giả định (assumed knowledge) là bằng cử nhân thuộc một lĩnh vực IT, một văn bằng graduate diploma đã hoàn thành, hoặc nhiều năm kinh nghiệm làm nghề IT.
Dòng kiến thức giả định là câu quan trọng nhất trên trang môn học, nhưng rất dễ bị đọc lướt qua. Môn học mặc định rằng bạn đã biết công nghệ thông tin vận hành ra sao, rồi dành trọn học kỳ cho mọi thứ bao quanh nó. INFO5990 không phải một môn kỹ thuật được thêm chút màu sắc nghề nghiệp. Đây là một môn rèn phán đoán nghề nghiệp, và nó tình cờ nằm trong một chương trình IT.
Hình thức học buổi tối còn cho bạn biết thêm một điều. Một phần đáng kể người trong lớp đang đi làm trong ngành vào ban ngày, và họ sẽ mang những ví dụ có thật vào giờ thảo luận. Nếu bạn là du học sinh học toàn thời gian và chưa có kinh nghiệm làm việc ở nước sở tại, bạn không thua về kiến thức, nhưng bạn phải cạnh tranh ở phần ví dụ minh hoạ. Khoảng cách đó lấp được bằng việc đọc và chuẩn bị tình huống, và bạn nên chủ động lấp nó thay vì hy vọng nó không lộ ra.
Trước khi tra cứu bất cứ điều gì: tiền tố INFO thuộc nhóm mã môn bị dùng lại nhiều nhất trong giáo dục đại học, gắn với các môn tin học ứng dụng, thư viện học và hệ thống thông tin ở nhiều trường trên nhiều châu lục. Bản thân Sydney cũng đang mở INFO5301, INFO5995 và bản trực tuyến OINF5990. Hãy tra theo tên môn thay vì tra mã trần, nếu không phần lớn kết quả tìm được sẽ thuộc về một chương trình khác.
Nếu không có đáp án đúng, vậy người ta chấm cái gì?
Trả lời trực tiếp: Theo các chuẩn đầu ra mà University of Sydney công bố cho môn này, người chấm thường chấm chất lượng lập luận của bạn trong những tình huống mà người làm nghề có năng lực vẫn bất đồng, cùng khả năng trình bày để người ngoài chuyên môn theo được. Toulmin (2003) gọi phần nối bằng chứng với kết luận là cơ sở bảo đảm (warrant), và đó thường là phần đẩy bài lên mức điểm cao.
Việc chuyển trọng tâm chấm điểm sang lập luận là điều chỉnh lớn nhất với sinh viên đi lên từ các môn lập trình và hệ thống, và nó giải thích phần lớn những điểm số đáng tiếc ở một môn như INFO5990. Một sinh viên mạnh về kỹ thuật thường viết ra kết luận rồi coi phần lập luận như giàn giáo, xong việc thì tháo đi. Ở môn này, phần lập luận chính là thứ được chấm. Một khuyến nghị không cho thấy con đường từ bằng chứng tới phán đoán thì không chấm được, dù cuối cùng nó hợp lý tới đâu. Weizenbaum (1976) đã vạch đúng ranh giới này giữa phán đoán và tính toán, khi cảnh báo rằng một chiếc máy tính đưa ra đáp án không giống một con người cân nhắc xem có nên hành động theo đáp án đó hay không, và đó cũng gần với điều môn này chấm.
| Môn kỹ thuật thưởng điểm cho | INFO5990 thưởng điểm cho |
|---|---|
| Đáp án đúng | Một lập trường bảo vệ được, với lập luận bày ra rõ ràng |
| Giải pháp hiệu quả | Ý thức về việc ai gánh chi phí của giải pháp đó |
| Xử lý đúng tình huống đã cho | Chỉ ra được điều mà đề bài đã bỏ sót |
| Sự chắc chắn ở kết luận | Mức tự tin có cân chỉnh, kèm giới hạn được nêu rõ |
| Độ chính xác của thuật ngữ kỹ thuật | Sự rõ ràng với người đọc không cùng chuyên môn |
Toulmin (2003) cho bạn đúng cấu trúc mà người chấm đang tìm, kể cả khi họ không gọi tên nó. Một lập luận cần có luận điểm (claim), dữ liệu chống đỡ luận điểm đó, một cơ sở bảo đảm giải thích vì sao dữ liệu ấy cho phép rút ra luận điểm ấy, và một mệnh đề giới hạn (qualifier) cho biết luận điểm đứng vững tới mức nào. Phần lớn bài yếu ở các môn thực hành nghề nghiệp có luận điểm và dữ liệu nhưng bỏ mất cơ sở bảo đảm, tức bỏ đúng phần mà Fisher (2011) coi là nơi lộ ra khả năng phán đoán chứ không chỉ khả năng nhớ lại kiến thức.
Lấy ví dụ một câu hỏi về việc một doanh nghiệp có nên chuyển hệ thống tính lương cũ lên một nhà cung cấp dịch vụ đám mây hay không. Một bài trình bày khoản tiết kiệm chi phí, lợi thế mở rộng quy mô, rồi khuyến nghị chuyển. Một bài mạnh hơn đi tới cùng khuyến nghị đó, nhưng nêu rõ cơ sở khiến khuyến nghị đứng vững, cụ thể là tải xử lý lương có thể dự đoán được và ràng buộc của doanh nghiệp nằm ở chi phí đầu tư ban đầu chứ không nằm ở yêu cầu lưu trữ dữ liệu trong nước, rồi bổ sung điều kiện mà nếu xảy ra thì khuyến nghị sẽ đảo chiều. Khuyến nghị không đổi. Điều thay đổi là bài thứ hai bày ra được con đường lập luận, và đó mới là thứ danh sách chuẩn đầu ra thật sự đòi hỏi.
Vì sao phần trả lời về đạo đức nghề nghiệp thường hụt điểm?
Trả lời trực tiếp: Vì sinh viên thường nhận diện được vấn đề đạo đức, gọi tên một khung lý thuyết rồi dừng lại, trong khi chuẩn đầu ra yêu cầu phân tích và giải quyết một tình huống lưỡng nan. Moor (1985) giải thích vì sao phần giải quyết mới khó, bởi công nghệ tạo ra những khoảng trống chính sách mà chưa quy tắc có sẵn nào lấp được.
Máy xạ trị Therac-25, thiết bị đã gây quá liều chết người cho bệnh nhân trong giai đoạn 1985 tới 1987 vì một lỗi tranh chấp thời điểm (race condition) trong phần mềm, là tình huống mà phần lớn các môn thực hành nghề nghiệp quay lại khi muốn cho thấy một quyết định kỹ thuật cũng là một quyết định đạo đức, như Leveson và Turner (1993) đã phân tích. Tình huống lưỡng nan là tình huống mà mọi lựa chọn đều phải trả giá bằng một thứ có giá trị. Nếu bài của bạn đi tới một hướng hành động mà không còn thiệt hại nào cần thừa nhận, gần như chắc chắn bạn đã biến tình huống lưỡng nan thành một câu hỏi về tuân thủ quy định rồi trả lời câu hỏi đó. Nhận ra vấn đề chỉ là tấm vé vào cửa, chưa phải phần trình diễn. Rest (1986) chia hành vi đạo đức thành bốn thành phần riêng biệt, gồm nhận ra vấn đề, phán đoán điều gì là đúng, quyết định hành động và thật sự hành động, và phần lớn bài yếu dừng lại sau thành phần đầu tiên trong khi điểm lại nằm ở ba thành phần sau.
Moor (1985) lập luận rằng máy tính sinh ra những tình huống đạo đức thật sự mới, chứ không chỉ là phiên bản mới của các tình huống cũ, vì công nghệ tạo ra những năng lực mà chưa có chính sách nào điều chỉnh. Ông gọi đó là khoảng trống chính sách (policy vacuum), và việc của đạo đức máy tính là lấp những khoảng trống ấy khi các khái niệm còn chưa rõ ràng. Nguyên văn của Moor là "A typical problem in computer ethics arises because there is a policy vacuum about how computer technology should be used" (Moor, 1985, p. 266). Floridi (2013) về sau đặt lại cả lĩnh vực quanh ý tưởng rằng bản thân thông tin, chứ không chỉ những cỗ máy xử lý nó, xứng đáng có một phạm trù đạo đức riêng, và cách nhìn này hữu ích khi một tình huống không vừa khít với quy tắc nghề nghiệp nào có sẵn. Cách đặt vấn đề ấy ảnh hưởng trực tiếp tới điểm của bạn. Theo Johnson (2001), cách với lấy một quy tắc có sẵn rồi áp dụng máy móc sẽ bỏ lỡ đúng loại tình huống chưa có quy tắc thoả đáng, và ở môn này đó lại chính là loại tình huống được chọn để ra đề.
Bộ quy tắc đạo đức nghề kỹ thuật phần mềm của Gotterbarn và cộng sự (1999), do Association for Computing Machinery (ACM) và IEEE Computer Society cùng xây dựng, hữu ích ở đây vì một lý do sinh viên hay bỏ qua. Bộ quy tắc được tổ chức quanh nghĩa vụ với từng bên riêng biệt, gồm công chúng, khách hàng, người sử dụng lao động, nghề nghiệp và đồng nghiệp, trong đó lợi ích công chúng được đặt lên trên hết khi các nghĩa vụ kéo về những hướng ngược nhau. Gotterbarn (1991) đã bảo vệ lập trường này từ lâu trước khi bộ quy tắc được chính thức hoá. Giá trị của bộ quy tắc trong bài tập là tấm bản đồ cho biết những bên nào có lợi ích liên quan, chứ không phải một thẩm quyền để trích dẫn rồi đi tiếp. Ở Úc, chuẩn nghề nghiệp tương đương là Code of Professional Conduct của Australian Computer Society, và tài liệu nào trong hai tài liệu này cũng có thể làm điểm tựa cho một đoạn về đạo đức, với điều kiện bạn lập luận từ nội dung của nó chứ không chỉ nêu tên.
Nissenbaum (2004) định nghĩa lại quyền riêng tư theo nguyên tắc toàn vẹn ngữ cảnh (contextual integrity). Theo cách nhìn này, một dòng thông tin được đánh giá không phải ở chỗ dữ liệu có được chia sẻ hay không, mà ở chỗ việc chia sẻ có khớp với chuẩn mực của ngữ cảnh nơi dữ liệu phát sinh hay không. Với một tình huống về xử lý dữ liệu, đây là công cụ sắc hơn phép cân nhắc chung chung giữa quyền riêng tư và lợi ích, và nó đi rất hợp với cách Solove (2008) mô tả rộng hơn về các dạng tổn hại quyền riêng tư.
Điểm thật sự nằm ở đâu: ở phần sau khi đã ra quyết định. Hãy gọi tên phương án bạn đã loại, nói rõ loại nó thì mất gì, và nêu điều gì phải thay đổi thì bạn sẽ chọn khác đi. Ba câu làm được việc đó có ích cho điểm số hơn hẳn một đoạn nữa kể lại dữ kiện của tình huống.
Lấy ví dụ một tình huống trong đó nhóm dự án phát hiện một lỗi ở giai đoạn muộn, và nếu bàn giao đúng hạn thì một số ít người dùng sẽ đối mặt với nguy cơ mất dữ liệu. Các bài yếu kết luận rằng nhóm phải công bố lỗi vì trung thực là nghĩa vụ nghề nghiệp. Một bài được chấm cao đi tới cùng kết luận đó, nhưng bàn thêm việc công bố gây thiệt hại thương mại cho khách hàng ra sao, vì sao thiệt hại đó không lớn hơn rủi ro người dùng phải chịu, và mức độ nghiêm trọng tới ngưỡng nào thì cán cân mới thật sự gây tranh cãi thay vì hiển nhiên.
Vì sao chuẩn đầu ra về nghiên cứu hay bị đọc như một dòng trang trí?
Trả lời trực tiếp: Chuẩn đầu ra LO6 yêu cầu vận dụng các phương pháp, mô hình và công cụ nghiên cứu điều tra vào thực hành nghề IT, nên môn này có một phần là môn phương pháp nghiên cứu, và đây thường là chuẩn đầu ra ít được chuẩn bị nhất. Flyvbjerg và Budzier (2011) là một ví dụ về loại nguồn đáp ứng được chuẩn đầu ra này, vì vừa gắn với thực tiễn ngành vừa nói rõ phương pháp.
Sinh viên thấy chữ nghiên cứu trong chuẩn đầu ra, hiểu rằng chỉ cần đi tìm vài nguồn, rồi nộp bài mà nền bằng chứng chỉ gồm tài liệu tiếp thị của nhà cung cấp và bài viết trên blog của các công ty tư vấn. Lập luận có thể chặt chẽ, nhưng lớp bằng chứng sụp đổ trước bất kỳ sự soi xét nào, và điều đó giữ điểm ở mức thấp bất kể phần còn lại tốt tới đâu.
Ranh giới cần phân biệt là giữa một nguồn báo cáo bằng chứng và một nguồn chỉ báo cáo kết luận. Một tài liệu trắng (white paper) của nhà cung cấp tuyên bố hiệu suất tăng 90% là một khẳng định về một khẳng định. Một nghiên cứu bình duyệt mô tả rõ phương pháp, mẫu và giới hạn mới là bằng chứng bạn có thể cân nhắc. Bạn được phép trích tài liệu của ngành, và ở một môn thực hành nghề nghiệp thì thường nên trích, nhưng phải xử lý nó như lời khai của một bên có lợi ích liên quan chứ không như một phát hiện khoa học. CHAOS Report của Standish Group, công bố lần đầu năm 1994, là một nguồn ngành khác được trích rộng rãi về tỉ lệ thất bại của dự án IT. Nguồn này đáng được nêu đích danh chính vì phương pháp của nó từng bị phê bình ở cách định nghĩa một dự án thành công, và đó là một sự thật bạn có thể dùng trong bài thay vì giấu đi.
Flyvbjerg và Budzier (2011) là mẫu tốt cho chuẩn mực này vì vừa sát thực tiễn ngành vừa nói rõ phương pháp. Phân tích của họ trên 1.471 dự án IT cho thấy mức vượt chi phí trung bình là 27%, trong khi cứ khoảng sáu dự án lại có một dự án vượt tới chừng 200%, và đó là một bức tranh khác hẳn so với khi chỉ nhìn con số trung bình. Số liệu này nằm trong một bài trên Harvard Business Review có tường phí, nên nếu định trích, bạn hãy tìm bản mở do chính các tác giả công bố thay vì dẫn lại qua một bài tóm tắt. Bài học dùng được ở chỗ khác không nằm ở con số. Nó nằm ở chỗ một phân phối cho bạn biết điều mà số trung bình che đi, và một bài chỉ trích số trung bình mà bỏ qua phần đuôi là một bài chưa đọc hết chính nguồn của mình.
Một phép thử trước khi trích bất kỳ nguồn nào: bạn có nói được ai thu thập dữ liệu, thu từ ai, và điều gì xảy ra thì kết quả đã khác đi hay không? Nếu không, bạn đang trích một lời khẳng định. Khi đó, hãy tìm nghiên cứu gốc nằm bên dưới nó, hoặc hạ mức khẳng định của bạn xuống cho khớp với bằng chứng bạn thật sự có.
Chuẩn bị cho chuẩn đầu ra về trình bày thế nào?
Trả lời trực tiếp: Hãy viết cho một người đọc có năng lực nhưng không cùng chuyên môn với bạn, vì đó là điều chuẩn đầu ra LO5 mô tả và cũng là việc người làm nghề thật sự được trả tiền để làm. Phân biệt của Brooks (1987) giữa độ phức tạp bản chất và độ phức tạp ngẫu nhiên giúp bạn quyết định chi tiết nào người đọc ngoài ngành cần biết và chi tiết nào nên nén lại.
Kiểu hỏng hay gặp không phải là sai ngữ pháp, mà là dùng thuật ngữ mà không xét lại. Đó là khi một từ chuyên ngành gánh một vai trò thật trong câu, còn người đọc không thể đánh giá lập luận nếu chưa biết sẵn từ đó nghĩa là gì. Trong thực tế nghề nghiệp, người nhận khuyến nghị của bạn thường là một giám đốc tài chính hay một trưởng bộ phận lâm sàng, và một khuyến nghị họ không đánh giá được là một khuyến nghị họ sẽ không làm theo.
Ba thói quen dưới đây mang lại phần lớn tiến bộ. Thứ nhất, đặt khuyến nghị ngay ở đoạn đầu thay vì dẫn dắt dần tới nó, vì người đọc trong doanh nghiệp đọc kỹ phần đầu rồi lướt phần còn lại. Thứ hai, giải thích thuật ngữ kỹ thuật ngay lần dùng đầu tiên bằng một mệnh đề ngắn, không sa đà. Thứ ba, nói về sự bất định bằng lời lẽ bình thường, vì câu "chúng tôi chưa có số liệu về tải cao điểm" vừa chuyên nghiệp hơn vừa hữu ích hơn một con số tự tin mà chẳng ai đo.
Brooks (1987) vẫn có mặt trong danh mục đọc của các môn thực hành nghề nghiệp gần 40 năm sau khi ra đời, nhờ sự phân biệt ông đặt ra giữa độ phức tạp bản chất (essential complexity) và độ phức tạp ngẫu nhiên (accidental complexity). Độ phức tạp bản chất của một hệ thống nằm ở chính bài toán mà hệ thống mô hình hoá, và không công cụ nào gỡ bỏ được nó. Sự phân biệt đó dùng được ngay khi bạn viết, vì nó cho bạn một tiêu chí có nguyên tắc để chọn chi tiết. Người đọc ngoài ngành cần những chi tiết thuộc độ phức tạp bản chất của quyết định, còn chi tiết triển khai thì có thể nén lại. Các khung chất lượng phần mềm như ISO/IEC 25010 cũng chính thức hoá một phiên bản của ranh giới này, giữa điều một hệ thống phải đem lại và cách hệ thống đó tình cờ được xây dựng.
Nên chuẩn bị rải đều cả học kỳ ra sao?
Trả lời trực tiếp: Hãy ghi một ghi chú ngắn ngay trong tối sau mỗi buổi seminar, gồm tình huống là gì, điều gì thật sự bị đặt lên bàn cân, và cuối cùng ai gánh chi phí. Những môn dạy bằng tình huống như môn này trừng phạt thói quen đợi tới tuần nộp bài mới bắt đầu, còn một học kỳ ghi chép cho bạn những ví dụ tự thu thập mà cả lớp không tìm thấy trên mạng.
Các môn dạy bằng tình huống khiến người bắt đầu muộn chịu thiệt, vì ràng buộc thật sự là kho ví dụ minh hoạ của bạn chứ không phải tốc độ viết. Một sinh viên đã gom ví dụ suốt học kỳ có thể viết một bài có gốc rễ trong vài buổi tối. Một sinh viên bắt đầu từ con số không thì tiêu gần hết thời gian chỉ để tìm ra một điều cụ thể để nói.
Cách rẻ nhất để giữ kỷ luật này là viết ghi chú ngay tối hôm đó, khi cuộc thảo luận vẫn còn rõ trong đầu. Làm đều như vậy thì tới lúc có bài đánh giá, bạn chọn trong đống chất liệu mình đã hiểu sẵn thay vì đi tìm một điều gì đó để nói. Lợi ích đi kèm cũng quan trọng gần như vậy, vì những tình huống bạn tự gom sẽ không trùng với những tình huống cả lớp tìm thấy ở trang kết quả tìm kiếm đầu tiên.
Danh sách môn xung khắc cũng cần để ý. Trang môn học của University of Sydney ghi INFO1111 và OINF5990 là hai môn xung khắc. Ở Sydney, tiền tố O đánh dấu bản học trực tuyến của một môn, và cặp mã này có vẻ đúng như vậy, dù trang chỉ nêu quy định xung khắc mà không giải thích. Hãy kiểm tra lại trên trang của đúng năm học của bạn trước khi đăng ký, vì các danh sách này được rà lại giữa các năm.
Người đọc thứ hai có tác dụng gì ở môn này?
Trả lời trực tiếp: Người đọc thứ hai bắt được bước bạn không còn tự nhìn thấy, vì khi lập luận đã viết xong, cơ sở bảo đảm còn thiếu vẫn có vẻ hiển nhiên với chính người viết. Mentor hỏi vì sao bằng chứng đó cho phép rút ra kết luận đó, xem bạn đã loại phương án nào và vì sao, rồi thử xem một người ngoài ngành IT có theo được đoạn bạn tưởng đã viết rõ hay không.
Điều khó nhất ở một môn rèn phán đoán là bạn không tự chấm được lập luận của chính mình. Viết xong một lập luận rồi, bạn không còn thấy bước mình đã bỏ qua, vì trong đầu bạn bước đó vẫn còn nguyên. Đó là khoảng trống cụ thể mà một mentor MAAS giúp lấp, và cũng là lý do các buổi làm việc giống một buổi chất vấn hơn là một buổi giảng bài.
Câu hỏi làm được nhiều việc nhất rất đơn giản, đó là vì sao bằng chứng đó cho phép bạn rút ra kết luận đó. Nếu câu trả lời thành thật là vì nó hiển nhiên, thì cơ sở bảo đảm đang thiếu trên trang giấy dù nó vẫn nằm trong đầu bạn. Từ đó, mentor sẽ hỏi bạn đã loại phương án nào và loại nó thì mất gì, nguồn bạn dựa vào đang báo cáo bằng chứng hay chỉ báo cáo kết luận của ai đó, và một người ngoài ngành IT sẽ hiểu ra sao cái đoạn bạn tưởng đã viết rõ.
Lập trường vẫn là của bạn, và bài viết cũng vậy. Điều thay đổi là lập luận của bạn đã đứng vững trước một lần phản bác có nghề trước khi người chấm nhìn thấy nó.
Câu hỏi thường gặp
Môn này thuộc trường nào?
Môn thuộc University of Sydney, nơi INFO5990 là Professional Practice in IT, môn sau đại học 6 tín chỉ do School of Computer Science thuộc Faculty of Engineering giảng dạy.
Có cần học gì trước khi đăng ký không?
Trang môn học không ghi môn tiên quyết và không ghi môn song hành bắt buộc, nhưng có nêu kiến thức giả định là bằng cử nhân thuộc một lĩnh vực IT, một văn bằng graduate diploma đã hoàn thành, hoặc kinh nghiệm nghề nghiệp đáng kể. Kiến thức giả định không bị kiểm tra lúc đăng ký, nên trách nhiệm lấp khoảng trống đó thuộc về bạn.
Có thể học môn này cùng một môn tương tự không?
Hai môn xung khắc được công bố là INFO1111 và OINF5990. Đã có tín chỉ ở một trong hai môn đó thì không đăng ký được môn này. Hãy kiểm tra lại trên trang của đúng năm học của bạn.
Môn học vào lúc nào và học theo hình thức gì?
Trang môn học cho thấy hai đợt mở lớp ở Semester 1 và Semester 2 năm 2026, học buổi tối tại Camperdown và Darlington. Cách tổ chức lớp có thể thay đổi giữa các năm, nên hãy xác nhận trước khi lên kế hoạch.
Không phải lập trình thì môn này có nhẹ không?
Bỏ phần lập trình không làm môn học nhẹ đi, nó chỉ dời chỗ khó sang nơi khác. Điểm ở đây phụ thuộc vào chất lượng lập luận, cách xử lý bằng chứng và độ rõ ràng với người đọc phổ thông, đều là những kỹ năng mà nhiều sinh viên mạnh về kỹ thuật ít có dịp luyện, nên họ cũng thường chuẩn bị thiếu.
Ví dụ trong bài nên kỹ thuật tới mức nào?
Đủ kỹ thuật để cụ thể, và được trình bày sao cho người ngoài ngành hiểu vì sao nó quan trọng. Một ví dụ được chọn khéo, chẳng hạn cách General Data Protection Regulation (GDPR) định hình lại việc xử lý dữ liệu ở nhiều ngành sau khi có hiệu lực năm 2018, có sức nặng hơn một tình huống chung chung. Chuẩn đầu ra LO5 yêu cầu trình bày phù hợp với người làm nghề IT trong môi trường doanh nghiệp, nghĩa là nội dung kỹ thuật vẫn giữ nguyên còn cách trình bày thì điều chỉnh theo người đọc.
Đọc thêm
Hỏi mentor MAAS về môn học của bạn
References
Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532
Fisher, A. (2011). Critical thinking: An introduction (2nd ed.). Cambridge University Press.
Flyvbjerg, B., & Budzier, A. (2011). Why your IT project may be riskier than you think. Harvard Business Review, 89(9), 23–25.
Floridi, L. (2013). The ethics of information. Oxford University Press.
Gotterbarn, D. (1991). Computer ethics: Responsibility regained. National Forum, 71(3), 26–31.
Gotterbarn, D., Miller, K., & Rogerson, S. (1999). Software engineering code of ethics is approved. Communications of the ACM, 42(10), 102–107. https://doi.org/10.1145/317665.317682
Johnson, D. G. (2001). Computer ethics (3rd ed.). Prentice Hall.
Leveson, N. G., & Turner, C. S. (1993). An investigation of the Therac-25 accidents. Computer, 26(7), 18–41. https://doi.org/10.1109/MC.1993.274940
Moor, J. H. (1985). What is computer ethics? Metaphilosophy, 16(4), 266–275. https://doi.org/10.1111/j.1467-9973.1985.tb00173.x
Nissenbaum, H. (2004). Privacy as contextual integrity. Washington Law Review, 79(1), 119–158.
Rest, J. R. (1986). Moral development: Advances in research and theory. Praeger.
Solove, D. J. (2008). Understanding privacy. Harvard University Press.
Toulmin, S. E. (2003). The uses of argument (Updated ed.). Cambridge University Press.
Weizenbaum, J. (1976). Computer power and human reason: From judgment to calculation. W. H. Freeman.
Winner, L. (1980). Do artifacts have politics? Daedalus, 109(1), 121–136.