SWE201c - Phần 4: Engineering Practices for Building Quality Software

Đáp án đúng: A. Một lỗi (fault) nằm trong mã nguồn chỉ trở thành sai sót thực sự khi đoạn mã chứa nó được thực thi. Nếu component chứa lỗi không bao giờ được gọi tới trong quá trình chạy, lỗi đó vẫn nằm im và không ai phát hiện ra — đây chính là lý do độ phủ mã (code coverage) quan trọng: phần mã chưa từng chạy là phần chưa từng được kiểm chứng. B, C sai: test data và test case là thứ ta chủ động tạo ra để kích hoạt lỗi, chúng là công cụ phát hiện chứ không phải nơi lỗi ẩn náu. D sai: output là kết quả quan sát được sau khi mã đã chạy — nếu đã có output sai thì lỗi đã lộ diện rồi.

Đáp án đúng: B. Ba chiến lược cutover phân biệt nhau ở mức độ sẵn sàng của hệ thống thay thế. Cold backup: máy thay thế chưa chạy, phải cài đặt và khởi động từ đầu. Warm standby: máy thay thế ĐANG CHẠY và sẵn sàng cho việc cài đặt — đúng mô tả trong đề. Hot failover: dịch vụ thay thế đã chạy sẵn và chỉ cần chuyển hướng dữ liệu sang, không phải cài gì thêm. A sai vì hot failover không còn bước cài đặt nào. C sai vì cold backup thì máy chưa chạy. D "Warm failover" không phải một chiến lược chuẩn trong danh mục này. ⚠ Bản đề in đáp án A. Chốt B vì trong chính bộ đề khác của môn, câu "replacement services are ready for the redirection of data with no installation" mới là Hot failover — hai câu ghép lại thành một cặp nhất quán, và cặp đó buộc câu này phải là Warm standby.

Đáp án đúng: B. Chi phí sửa một khiếm khuyết tăng theo cấp số nhân theo độ trễ phát hiện: lỗi tìm thấy lúc review thiết kế chỉ mất vài giờ, cũng lỗi ấy lọt tới pha kiểm thử cuối thì kéo theo sửa mã, sửa tài liệu, kiểm thử hồi quy và cả những đoạn mã đã xây chồng lên phần sai. Hoãn kiểm soát chất lượng vì thế làm khối lượng làm lại (rework) phình lên và nợ kỹ thuật tích tụ. A sai: hệ quả về lịch giao hàng chỉ là hậu quả gián tiếp, không phải nguy cơ cốt lõi. C và D nói ngược: hoãn kiểm soát chất lượng làm tăng tổng chi phí và kéo dài dự án chứ không tiết kiệm hay tăng tốc.

Đáp án đúng: C. Câu này hỏi về mức độ gắn kết (cohesion) — càng yếu càng không mong muốn. Nhóm các chức năng chỉ vì chúng "xảy ra cùng khoảng thời gian" chính là temporal cohesion, một trong bốn loại cohesion yếu, vì module hình thành do trùng thời điểm chứ không do liên quan về nghiệp vụ. A là functional cohesion — mức mạnh nhất, đáng mong muốn nhất. B là object cohesion (thao tác trên thuộc tính của chính đối tượng), cũng thuộc nhóm mạnh. D là communicational cohesion (cùng dùng chung dữ liệu đầu vào), vẫn khá hơn temporal. Vì vậy C là lựa chọn kém mong muốn nhất.

Đáp án đúng: A. Validation trả lời câu hỏi "Are we building the right product?" — sản phẩm có thực sự đáp ứng nhu cầu và kỳ vọng của người dùng hay không. Việc phần mềm được người dùng đón nhận tốt chính là bằng chứng trực tiếp cho điều đó. B, C, D đều là verification ("Are we building the product right?"): B đối chiếu kết quả với tài liệu đặc tả, C và D kiểm tra hệ thống có hành xử đúng như quy định kỹ thuật đã viết ra hay không. Cả ba đều so sánh sản phẩm với đặc tả, chứ không hỏi bản thân đặc tả có đúng ý người dùng.

Đáp án đúng: A, C, D. Phân tích tĩnh đọc mã nguồn mà không chạy chương trình, nên nó bắt được những gì suy ra được từ cấu trúc mã: biến khai báo mà không dùng, đoạn mã trùng lặp, và các mẫu cấp phát - giải phóng bộ nhớ dẫn tới rò rỉ. B sai: tính khả thi của yêu cầu (requirements feasibility) là chuyện nghiệp vụ và ràng buộc dự án, nằm ngoài mã nguồn — không công cụ phân tích tĩnh nào đọc mã mà kết luận được yêu cầu có làm nổi hay không. Đây là ranh giới cần nhớ: phân tích tĩnh soi mã, không soi yêu cầu.

Đáp án đúng: A. Trong Observer Pattern, Subject truyền chính nó (thường là tham chiếu this) sang Observer khi gọi update, để Observer biết ai vừa đổi và tự lấy dữ liệu mới về — đây gọi là mô hình pull và là cách cài đặt tiêu chuẩn, hoàn toàn không bị chặn bởi phụ thuộc vòng. Vì vậy A là phát biểu SAI. B đúng: Subject chỉ phụ thuộc vào interface Observer chứ không phụ thuộc lớp cụ thể — đúng tinh thần Dependency Inversion. C đúng: Strategy cho phép thêm thuật toán mới bằng cách thêm lớp mới, không phải sửa lớp cũ, tức mở để mở rộng và đóng để sửa đổi.

Đáp án đúng: D. Một design pattern được mô tả đầy đủ luôn gồm ba phần: bối cảnh và vấn đề nó giải quyết (problem description), cấu trúc giải pháp gồm các lớp và quan hệ (solution description), và hệ quả khi áp dụng — được gì, đánh đổi gì (consequences). Thiếu phần hệ quả thì người đọc không biết khi nào KHÔNG nên dùng mẫu đó. A, B, C mỗi phương án chỉ nêu một phần trong ba, nên đều thiếu; chỉ D bao trọn.

Đáp án đúng: B. Trong bốn phương án, chỉ độ tin cậy (reliability) là một thuộc tính chất lượng của phần mềm — khả năng hệ thống thực hiện đúng chức năng trong điều kiện xác định suốt một khoảng thời gian. Nó nằm cùng nhóm với tính bảo trì, hiệu năng, bảo mật, khả dụng. A, C, D đều chỉ là các loại giao diện: giao diện người dùng, giao diện phần mềm và giao diện phần cứng. Giao diện là thành phần của hệ thống, không phải thước đo chất lượng của hệ thống.

Đáp án đúng: C. Hệ thống ngân hàng trực tuyến có nhiều client (trình duyệt, ứng dụng di động) gửi yêu cầu tới một tập máy chủ tập trung nắm dữ liệu tài khoản và xử lý giao dịch — đúng khuôn mẫu Client-Server: phân tách rõ bên yêu cầu dịch vụ và bên cung cấp dịch vụ, giao tiếp qua mạng. A Pipe-and-Filter hợp với xử lý dữ liệu theo chuỗi biến đổi. B Blackboard hợp bài toán AI nhiều nguồn tri thức cùng ghi lên một vùng dữ liệu chung. D Event-based hợp hệ thống phản ứng theo sự kiện rời rạc. Không mô hình nào trong ba nắm được đặc trưng tập trung dữ liệu và nhiều người dùng đồng thời của ngân hàng.

Đáp án đúng: C. Lập kế hoạch triển khai (deployment planning) là bài toán kỹ thuật vận hành: trình tự các bước cài đặt, thứ tự khởi động dịch vụ, di trú dữ liệu, cấu hình môi trường, kiểm tra sau cài và phương án quay lui khi hỏng. Không có trình tự này thì buổi go-live biến thành ứng biến. A thuộc pha thiết kế giao diện. B thuộc phòng marketing. D là đầu vào cho bài toán năng lực hệ thống (capacity planning) chứ không phải nội dung của kế hoạch triển khai. Chỉ C trực tiếp quyết định buổi triển khai thành hay bại.

Đáp án đúng: A. Cohesion đo mức độ gắn bó BÊN TRONG một module — mọi thành phần của module có cùng phục vụ một mục đích rõ ràng hay không. Cohesion cao nghĩa là module làm đúng một việc và làm trọn. B decomposability là lợi ích của tính module nói chung. C và D đều nói về coupling chứ không phải cohesion: giữ thay đổi không lan qua ranh giới module và giao tiếp lỏng lẻo giữa các module đều là chuyện quan hệ GIỮA các module. Nhớ cặp đối: cohesion nhìn vào trong, coupling nhìn ra ngoài.