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.
Coursera: Introduction to Software Engineering - SWE201c
Chủ đề học tập
MOOC 01 - Software Development Processes and Methodologies (SWE201c)
Khoá thứ nhất của chuyên ngành, địa chỉ coursera.org/learn/software-processes. Ứng với CLO1, trải buổi 1 đến buổi 4, buổi 1 có kèm thành phần Offline 1 giới thiệu khoá học tại campus và phần dẫn nhập cả chuyên ngành. Hai buổi đầu bàn quy trình phát triển phần mềm: quy trình là gì, khác gì phương pháp luận, gồm những hoạt động nào, cùng phần yêu cầu với yêu cầu chức năng, yêu cầu phi chức năng và mô hình tham chiếu WRSPM. Buổi 3 đi vào các mô hình truyền thống gồm thác nước, mô hình chữ V, sashimi, tăng dần, lặp, xoắn ốc, Unified Process và stage-gate. Buổi 4 giới thiệu hai họ agile và lean để đối chiếu với nhóm truyền thống, chuẩn bị cho hai khoá kế tiếp. Chuẩn đầu ra tương ứng là so sánh được các phương pháp luận theo ràng buộc môi trường, tổ chức và sản phẩm.
MOOC 02 - Agile Software Development (SWE201c)
Khoá thứ hai của chuyên ngành, địa chỉ coursera.org/learn/agile-software-development. Ứng với CLO2, trải buổi 5 và buổi 6. Buổi 5 gồm phần nền tảng agile và phần yêu cầu cùng lập kế hoạch: bốn giá trị của Tuyên ngôn Agile và mười hai nguyên tắc đi kèm, cách viết user story theo tiêu chí INVEST, các kỹ thuật ước lượng, lập kế hoạch phát hành và kế hoạch cho từng vòng lặp. Buổi 6 gồm Scrum và Extreme Programming: Scrum với ba vai trò, bốn sự kiện gồm họp kế hoạch sprint, họp hằng ngày, họp rà soát và họp cải tiến, các tạo tác gồm product backlog, sprint backlog và phần tăng trưởng, cùng biểu đồ burndown theo dõi tiến độ; XP với lập trình cặp, đội hình toàn diện, phát hành nhỏ và vòng phản hồi ngắn. Chuẩn đầu ra tương ứng là tham gia hiệu quả vào quy trình và thực hành agile.
MOOC 03 - Lean Software Development (SWE201c)
Khoá thứ ba của chuyên ngành, địa chỉ coursera.org/learn/lean-software-development. Ứng với CLO3, trải buổi 7 và buổi 8. Buổi 7 gồm phần nền tảng lean và phần công cụ: bảy nguyên tắc lean gồm loại bỏ lãng phí, khuếch đại việc học, quyết định càng muộn càng tốt, giao hàng càng nhanh càng tốt, trao quyền cho đội, xây chất lượng từ gốc và nhìn tổng thể; Kanban cho phát triển phần mềm với bảng công việc, giới hạn số việc đang làm và quản trị dòng chảy; lập bản đồ dòng giá trị để thấy chỗ nào trong quy trình đang sinh ra chờ đợi; và kaizen tức cải tiến liên tục từng bước nhỏ. Buổi 8 gồm Lean Startup với sản phẩm khả dụng tối thiểu, vòng lặp xây dựng - đo lường - học hỏi và kế toán đổi mới, cùng Design Thinking. Chuẩn đầu ra tương ứng là áp dụng được kỹ thuật lean vào phát triển phần mềm.
MOOC 04 - Engineering Practices for Building Quality Software (SWE201c)
Khoá thứ tư và cũng là khoá khép lại chuyên ngành, địa chỉ coursera.org/learn/engineering-practices-secure-software-quality. Ứng với CLO4, trải buổi 9 đến buổi 12; buổi 12 có kèm thành phần Offline 2 ôn lại toàn bộ chuyên ngành tại campus. Khoá đi theo đúng thứ tự các giai đoạn kỹ thuật. Buổi 9 gồm phần nhập môn phần mềm chất lượng và chất lượng trong thiết kế: tính mô-đun, ghép nối và kết dính, che giấu thông tin, các mẫu thiết kế. Buổi 10 là chất lượng trong kiến trúc: các kiểu kiến trúc và cách kiến trúc quyết định thuộc tính chất lượng của hệ thống. Buổi 11 là chất lượng trong hiện thực: chuẩn viết mã, rà soát mã, phân tích tĩnh, tái cấu trúc và quản lý phiên bản. Buổi 12 là chất lượng trong kiểm thử và triển khai: phân biệt verification với validation, các mức kiểm thử, tích hợp và triển khai.
Đề thi trắc nghiệm
Xem tất cảSWE201c
Coursera: Introduction to Software Engineering - SWE201c
SWE201c_DE_399 - Có đáp án và giải thích chi tiết
SWE201c
Coursera: Introduction to Software Engineering - SWE201c
SWE201c_DE_297 - Có đáp án và giải thích chi tiết
SWE201c
Coursera: Introduction to Software Engineering - SWE201c
SWE201c_FE_SU26 - Có đáp án và giải thích chi tiết
Bắt đầu một phiên học theo môn
Tiến độ của bạn sẽ luôn được tính toán và đồng bộ trực tiếp theo tổng số lượng câu hỏi mới nhất của môn học này.
Bạn cần đăng nhập để bắt đầu học từ ngân hàng câu hỏi và lưu tiến độ theo môn.
Đang tải phân bố độ khó.
Ngân hàng câu hỏi
Xem trước · Cuộn vô hạnĐá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.