Ngân hàng câu hỏi môn Coursera: Introduction to Software Engineering - SWE201c

Mục tiêu chính của kiến trúc phần mềm trong quá trình phát triển phần mềm là xác định các mối quan tâm xuyên suốt và rộng lớn hơn cho hệ thống. Kiến trúc phần mềm tập trung vào việc giải quyết các vấn đề phức tạp và liên quan đến nhiều thành phần khác nhau của hệ thống, bao gồm cả các yêu cầu chức năng, hiệu suất, bảo mật và khả năng mở rộng. Điều này giúp đảm bảo rằng hệ thống được thiết kế và xây dựng một cách toàn diện và linh hoạt, đáp ứng được nhu cầu của người dùng và dễ dàng mở rộng trong tương lai.

Đáp án đúng: B. Communication là một trong năm giá trị cốt lõi của XP (cùng Simplicity, Feedback, Courage, Respect). XP cho rằng phần lớn vấn đề dự án bắt nguồn từ việc ai đó không nói với ai đó điều gì đó, nên giao tiếp hiệu quả và liên tục là cách gỡ vướng nhanh nhất — đây cũng là lý do XP đề cao pair programming, ngồi chung và khách hàng tại chỗ. A hạn chế giao tiếp và D chỉ trao đổi bằng văn bản đều đi ngược nguyên tắc ưu tiên đối thoại trực tiếp. C phủ nhận vai trò của giao tiếp, sai hoàn toàn với cả XP lẫn Agile nói chung.

Đáp án đúng: A, B. Theo bộ khung Rozanski & Woods mà môn học dùng, viewpoint mô tả một lát cắt cấu trúc của hệ thống: Functional, Information, Concurrency, Development, Deployment, Operational. Perspective là mối quan tâm cắt ngang mọi view: Security, Performance and Scalability, Availability and Resilience, Evolution. A và B là hai viewpoint chuẩn trong danh sách trên. C "Usability perspective" và D "Maintenance perspective" đều KHÔNG có trong bộ perspective mà môn dạy — mối quan tâm gần nhất với bảo trì được gọi là Evolution, không phải Maintenance.

Đáp án đúng: A. INVEST là bộ sáu tiêu chí cho một user story tốt: Independent (độc lập), Negotiable (thương lượng được), Valuable (có giá trị), Estimable (ước lượng được), Small (đủ nhỏ), Testable (kiểm thử được). Trong bốn phương án chỉ "Valuable" nằm trong bộ này. B Imprecise (mơ hồ) đi ngược Testable và Estimable. C Rigid (cứng nhắc) đi ngược Negotiable. D Expansive (phình to) đi ngược Small. Ba phương án nhiễu được dựng bằng cách lấy phản nghĩa của chính các chữ cái trong INVEST.

Đáp án đúng: A. Acceptance test là hình thức validation trực tiếp nhất trong Agile: nó biến yêu cầu của người dùng thành các tiêu chí kiểm chứng được, để cả nhóm và khách hàng cùng thống nhất thế nào là "xong". Nhờ đó tránh được tình huống phần mềm chạy đúng đặc tả nhưng không đúng nhu cầu. B cải thiện tài liệu, C tăng cộng tác nhóm và D quản lý thời gian tốt hơn đều là lợi ích PHỤ có thật, nhưng câu hỏi hỏi lợi ích CHÍNH trong tương quan với yêu cầu người dùng — đó là việc thẩm định yêu cầu.

Đáp án đúng: B. Ba loại coupling chặt là content coupling (một module chạm thẳng vào nội dung bên trong module khác), common coupling (nhiều module cùng dùng dữ liệu toàn cục) và external coupling (các module cùng phụ thuộc vào một định dạng, giao thức hay thiết bị bên ngoài). A trộn control và data structure (nhóm trung bình) với message (nhóm lỏng). C phủ nhận sự tồn tại của coupling chặt, sai hiển nhiên. D liệt kê đúng nhóm LỎNG (data, message, none) — đây là bẫy đối xứng với câu hỏi về loose coupling, đọc nhanh rất dễ chọn nhầm.

Đáp án đúng: B. Scrum giả định phần lớn dự án phần mềm là bài toán phức tạp (complex domain): không thể biết trước toàn bộ lời giải, mà giải pháp tốt hơn dần hiện ra qua từng vòng lặp khi nhóm và khách hàng cùng nhìn thấy sản phẩm thật. "Learn as we go" chính là cách khai thác đặc tính tiến hoá này. A cải thiện quan hệ với khách hàng là hệ quả phụ tốt đẹp, không phải lý do. C tránh mất thời gian phân tích đầu dự án là cách diễn giải tiêu cực và sai — Scrum không né phân tích, nó trải phân tích ra suốt dự án. D ngăn giao hàng trễ cũng là hệ quả chứ không phải nguyên nhân.

Đáp án đúng: A. Scrum chỉ có ba vai trò (accountability): Product Owner, Scrum Master và Developers (nhóm phát triển). Project Manager KHÔNG nằm trong đó — các trách nhiệm truyền thống của vai trò này được phân tán: quản trị phạm vi và giá trị về Product Owner, gỡ vướng và bảo vệ quy trình về Scrum Master, còn lập kế hoạch và phân công về chính nhóm tự tổ chức. B, C, D đều là ba vai trò thật của Scrum, nên không phải đáp án của câu hỏi phủ định này.

Đáp án đúng: B. Bốn loại cohesion yếu, xếp từ yếu nhất lên: coincidental (gom ngẫu nhiên), temporal (cùng chạy trong một khoảng thời gian), procedural (theo một trình tự thực thi), logical association (cùng một loại công việc). A xếp nhầm sequential vào nhóm yếu — sequential thuộc nhóm trung bình, nơi đầu ra của phần này là đầu vào của phần kia. C liệt kê toàn nhóm trung bình và mạnh (communicational, sequential, object, functional). D phủ nhận sự tồn tại của cohesion yếu, hiển nhiên sai.

Đáp án đúng: A, C, D. Daily standup 15 phút phục vụ ba việc: nhóm tự lập kế hoạch cho ngày làm việc, phối hợp với nhau về những phần công việc giao thoa, và cùng nắm tình hình tiến độ hướng tới Sprint Goal. B sai ở một chữ: "overlooking obstacles" nghĩa là BỎ QUA vật cản, trong khi mục đích thật của standup là NÊU RA vật cản (raising impediments) để Scrum Master gỡ. Đây là bẫy chữ nghĩa — nếu đọc lướt thành "overlook = xem xét" thì chọn nhầm ngay.

Đáp án đúng: B. Vấn đề lớn nhất của mô hình dự đoán là mọi khâu kiểm chứng đều dồn về cuối: tích hợp ở cuối, kiểm thử ở cuối, người dùng nhìn thấy sản phẩm ở cuối. Hậu quả là hiểu sai yêu cầu hay lỗi thiết kế có thể nằm im suốt nhiều tháng, tới lúc lộ ra thì đã xây chồng rất nhiều thứ lên phần sai. A, C, D đều là ưu điểm chứ không phải vấn đề, và cả ba đều KHÔNG đúng với Waterfall: nó không có vòng phản hồi liên tục, không lấy cộng tác làm trọng tâm, và chi phí thay đổi tăng chứ không giảm theo thời gian.

Đáp án đúng: B. Agile cần vòng phản hồi ngắn và khả năng thay đổi mà không sợ vỡ. Continuous integration kèm bộ unit test tự động đáp ứng đúng điều đó: mỗi lần commit là chạy lại toàn bộ test, lỗi hồi quy lộ ra trong vài phút thay vì vài tuần, nhờ vậy nhóm dám refactor liên tục. A dồn kiểm thử về cuối là mô hình Waterfall. C hồi quy thủ công mỗi lần phát hành thì không theo kịp nhịp sprint và rất dễ bỏ sót. D né tài liệu chẳng liên quan gì tới cách kiểm thử, và Agile cũng không chủ trương bỏ tài liệu.

Đáp án đúng: D. Burndown chart trả lời được cả ba: nhìn tung độ tại ngày hiện tại biết còn bao nhiêu việc; so đường thực tế với đường lý tưởng biết có kịp mục tiêu sprint không; nhìn độ dốc qua nhiều ngày thấy xu hướng tiến triển (phẳng nhiều ngày là dấu hiệu tắc nghẽn). A, B, C mỗi phương án chỉ nêu một trong ba công dụng nên đều chưa đủ. Đây là dạng câu có phương án bao trùm: kiểm tra từng mục con, cả ba đều đúng thì chọn "All of the above".

Đáp án đúng: C. Đường ống của UNIX, nơi đầu ra của chương trình này thành đầu vào của chương trình kia, là ví dụ giáo khoa của Pipe-and-Filter: mỗi chương trình là một filter biến đổi dòng dữ liệu, các pipe nối chúng lại; filter không biết gì về nhau nên rất dễ ghép lại theo tổ hợp mới. A Blackboard dùng cho hệ tri thức nhiều nguồn cùng ghi lên vùng dữ liệu chung. B Layered chia hệ thống theo tầng dịch vụ. D Event-based phản ứng theo sự kiện rời rạc. E Client-Server tách bên yêu cầu và bên phục vụ. Không mô hình nào trong bốn nắm được đặc trưng dòng chảy tuần tự của pipeline.

Đáp án đúng: C. Xác định chính xác nhu cầu người dùng được coi là phần khó nhất của kỹ nghệ phần mềm: người dùng thường không nói rõ được điều mình cần, nhu cầu thay đổi theo thời gian, các bên liên quan mâu thuẫn nhau, và sai ở bước này thì mọi công sức phía sau đều đi lệch. Fred Brooks gọi đây là phần "essential" khó nhất, không có viên đạn bạc nào giải quyết được. A viết mã theo thiết kế đã có là phần cơ học nhất. B kiểm thử với người dùng tuy tốn công nhưng có quy trình rõ ràng. D định giá thị trường là bài toán kinh doanh, nằm ngoài quy trình phát triển phần mềm.