Font size
WorksheetsNMCNPM - Chương 2
Total questions: 79
Worksheet time: 40mins
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm vừa và nhỏ với vòng đời ngắn, bạn sẽ chọn mô hình nào sau đây?
Mô hình tăng trưởng
Mô hình làm bản mẫu
Mô hình RAD
Mô hình tiến hóa
Mô hình nào sau đây KHÔNG phù hợp cho việc kỹ nghệ phần mềm có yêu cầu thay đổi?
Mô hình làm bản mẫu
Mô hình thác nước
Mô hình phát triển nhanh RAD
Mô hình xoắn ốc
Hai mô hình nào sau đây sẽ không thể cho ra sản phẩm đạt yêu cầu nếu không có sự tham gia của khách hàng?
Mô hình RAD & mô hình thác nước.
Mô hình RAD & xoắn ốc.
Mô hình thác nước & xoắn ốc.
Mô hình RAD & mô hình làm bản mẫu.
Mô hình phát triển phần mềm nào được chọn nếu đội ngũ phát triển của công ty ít kinh nghiệm trong các dự án tương tự?
Mô hình thác nước.
Mô hình tăng trưởng.
Mô hình xoắn ốc.
RAD.
Hoạt động nào sau đây trong tiến trình phần mềm tổng quát cung cấp báo cáo phản hồi của khách hàng?
Mô hình hóa
Giao tiếp
Thiết kế
Triển khai
Phương án nào sau đây KHÔNG nêu đúng ưu điểm của quy trình phát triển phần mềm theo mô hình thác nước?
Quá trình phát triển đơn giản nên phù hợp với những dự án có ít thay đổi.
Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng nên dễ phân công công việc, phân bổ chi phí, giám sát công việc.
Giảm thiểu các lỗi mắc phải trong giai đoạn thiết kế.
Sửa lỗi dễ dàng và tốn ít chi phí.
Nhận định nào sau đây đúng về ưu điểm của mô hình làm bản mẫu (Prototyping Model) so với mô hình thác nước (Waterfall Model)?
Mô hình làm bản mẫu cho phép người dùng cung cấp tất cả các yêu cầu trước khi phát triển.
Mô hình làm bản mẫu cho phép người dùng điều chỉnh yêu cầu trên nguyên mẫu trước khi hệ thống thực sự được phát triển.
Mô hình làm bản mẫu giúp giảm thời gian phát triển phần mềm so với mô hình thác nước.
Mô hình làm bản mẫu giúp giảm thời gian phát triển phần mềm so với mô hình thác nước.
Phát biểu nào sau đây mô tả đúng cách mô hình tăng trưởng (Incremental Model) giúp giảm rủi ro trong các dự án lớn so với mô hình thác nước?
Mô hình tăng trưởng giúp phát triển hệ thống theo từng phần nhỏ, cho phép kiểm thử sớm và điều chỉnh dựa trên phản hồi từ mỗi phần.
Mô hình tăng trưởng không yêu cầu tài liệu hóa như mô hình thác nước.
Mô hình tăng trưởng phát triển toàn bộ hệ thống ngay từ đầu mà không cần qua các giai đoạn lặp lại.
Mô hình tăng trưởng yêu cầu tất cả các yêu cầu phải được xác định trước khi phát triển bắt đầu.
Nhược điểm nào của mô hình tăng trưởng (Incremental Model) có thể gây khó khăn cho việc xác định yêu cầu của người dùng?
Mô hình tăng trưởng cho phép người dùng cung cấp tất cả các yêu cầu trước khi phát triển.
Mô hình tăng trưởng có thể khiến người dùng thay đổi yêu cầu khi họ dần ra sản phẩm cuối cùng cho mỗi phần nhỏ.
Mô hình tăng trưởng yêu cầu lập kế hoạch chi tiết cho tất cả các phần trước khi phát triển bắt đầu.
Mô hình tăng trưởng không cho phép kiểm thử sản phẩm trước khi tất cả các phần hoàn thành
So với mô hình làm bản mẫu, mô hình tiến hóa (Evolutionary Model) có ưu điểm nào trong việc xử lý các yêu cầu thay đổi?
Mô hình tiến hóa yêu cầu hoàn thành tất cả các yêu cầu ngay từ đầu.
Mô hình tiến hóa cho phép yêu cầu thay đổi liên tục trong suốt quá trình phát triển, không chỉ dựa trên các nguyên mẫu ban đầu.
Mô hình tiến hóa không cho phép điều chỉnh yêu cầu sau khi phát triển bắt đầu.
Mô hình tiến hóa không cần sự tham gia của khách hàng trong suốt quá trình phát triển.
Nhận xét nào sau đây đúng về cách mô hình chữ V (V-Model) khắc phục nhược điểm của mô hình thác nước?
Mô hình chữ V không yêu cầu lập kế hoạch trước.
Mô hình chữ V kết hợp việc kiểm thử ngay từ giai đoạn phát triển, giúp đảm bảo chất lượng sản phẩm.
Mô hình chữ V không cần tham gia của khách hàng trong giai đoạn kiểm thử.
Mô hình chữ V cho phép hoàn quy các lắc giữa giai đoạn trước đó cho yêu cầu mới.
Trong một dự án Agile, nếu nhóm phát hiện rằng yêu cầu của khách hàng thay đổi trong giữa chu kỳ phát triển, nhóm nên làm gì?
Tiếp tục hoàn thành các nhiệm vụ theo kế hoạch ban đầu và xem xét yêu cầu mới sau khi hoàn thành.
Đưa ra giải pháp tạm thời để hoàn thành yêu cầu ban đầu và chuyển sang yêu cầu mới trong sprint tiếp theo.
Tạm dừng tiến trình, tổ chức một cuộc họp ngay lập tức với khách hàng để làm rõ yêu cầu và điều chỉnh kế hoạch.
Ghi nhận yêu cầu mới và tích hợp vào Sprint tiếp theo mà không cần sự thông báo với khách hàng.
Khi một dự án Agile gặp phải sự chậm trễ do thiếu nguồn lực hoặc kỹ năng, nhóm Agile nên ưu tiên làm gì?
Tăng cường giờ làm việc của nhóm để đảm bảo kịp tiến độ đã cam kết với khách hàng.
Thay đổi phạm vi công việc để không báo cho khách hàng về việc trì hoãn.
Đánh giá lại backlog, tập trung vào các tính năng có giá trị cao và giảm thiểu yêu cầu không quan trọng.
Mở rộng để tuyển thêm nhân sự có kỹ năng đáp ứng yêu cầu.
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm vừa và nhỏ trong một khoảng thời gian dài với yêu cầu của khách hàng đã được phân tích rõ ràng, quá trình phát triển và quy trình quản lý có tính tổ chức và hệ thống, phát hiện lỗi sớm do kiểm thử được lập kế hoạch song song với phát triển, bạn sẽ chọn mô hình nào sau đây?
Mô hình thác nước
Mô hình chữ V
Mô hình xoắn ốc
Mô hình RAD
Trong một hệ thống phát triển dựa trên mô hình Kỹ nghệ hướng thành phần (CBSE), một hệ thống phần mềm cần được nâng cấp để bổ sung chức năng mới mà thành phần hiện có không hỗ trợ. Nhóm phát triển cần ưu tiên thực hiện hành động nào?
Viết lại toàn bộ chức năng mới từ đầu để tích hợp vào hệ thống.
Tìm kiếm thành phần đã được phát triển sẵn, để tái sử dụng và tích hợp vào hệ thống, nhằm tiết kiệm thời gian và chi phí.
Biên dịch lại hệ thống hiện tại để tất cả các thành phần hiện tại trước khi phát triển chức năng mới.
Thay thế toàn bộ các thành phần cũ bằng các thành phần mới để đảm bảo hệ thống đồng nhất.
Phương án nào sau đây KHÔNG nêu đúng một pha của mô hình làm bản mẫu?
Kỹ nghệ
Làm mịn bản mẫu
Lập trình
Thiết kế nhanh
Trong các phát biểu dưới đây, phát biểu nào là ĐÚNG?
Mô hình thác nước phù hợp nếu lịch trình phát triển dự án rất chặt chẽ.
Mô hình RAD phù hợp với phần mềm có yêu cầu về độ tin cậy cao.
Mô hình xoắn ốc phù hợp với phần mềm có yêu cầu về độ tin cậy cao.
Thông thường, chi phí cho bảo trì nhiều hơn chi phí sản xuất phần mềm.
Mục đích của quy trình phần mềm là nhằm đưa ra phần mềm ____. Phương án nào dưới đây phù hợp nhất để điền vào chỗ trống?
có chất lượng, có thời gian và chi phí hợp lý.
có chất lượng và nhanh nhất có thể.
Càng nhanh và tốn ít chi phí càng tốt.
đúng thời hạn, chất lượng cao, không quan tâm đến chi phí.
RAD viết tắt của từ nào sau đây?
Không từ nào
Relative Application Development
Rapid Application Document
Rapid Application Development
Phương án nào sau đây mô tả đúng về ưu điểm chính của mô hình tăng trưởng?
Được dùng khi cần đưa sản phẩm ra thị trường sớm.
Dễ kiểm thử và debug.
Dễ kiểm thử và debug và được dùng khi cần đưa sản phẩm ra thị trường sớm.
Khách hàng có thể phản hồi sau mỗi lần tăng trưởng.
Ưu điểm chính của mô hình làm bản mẫu (Prototyping Model) giúp khắc phục hạn chế của mô hình thác nước đối với việc đáp ứng yêu cầu người dùng?
Tạo ra các nguyên mẫu giúp người dùng dễ dàng điều chỉnh yêu cầu trong quá trình phát triển.
Giảm thiểu sự tham gia của khách hàng trong quá trình phát triển.
Loại bỏ sự cần có tài liệu hóa chi tiết.
Giảm thiểu thời gian phát triển và đưa ra sản phẩm nhanh hơn.
So với mô hình RAD (Rapid Application Development), mô hình thác nước (Waterfall Model) có nhược điểm nào về sự tham gia của khách hàng?
Mô hình thác nước không cho phép khách hàng thay đổi yêu cầu sau khi quá trình phát triển bắt đầu.
Mô hình thác nước yêu cầu khách hàng tham gia liên tục trong suốt quá trình phát triển.
Mô hình thác nước cho phép khách hàng điều chỉnh yêu cầu thông qua các nguyên mẫu nhanh chóng.
Mô hình thác nước không yêu cầu sự tham gia của khách hàng trong quá trình kiểm thử.
Nhận xét nào sau đây đúng về cách mô hình xoắn ốc (Spiral Model) xử lý rủi ro so với mô hình thác nước?
Mô hình xoắn ốc loại bỏ việc kiểm thử phần mềm đến khi sản phẩm hoàn thành.
Mô hình xoắn ốc không đánh giá rủi ro trong quá trình phát triển.
Mô hình xoắn ốc yêu cầu tất cả các yêu cầu phải được xác định ngay từ đầu như mô hình thác nước..
Mô hình xoắn ốc kết hợp đánh giá rủi ro trong mỗi chu kỳ lặp, giúp quản lý rủi ro tốt hơn so với mô hình thác nước.
Điểm yếu nào của mô hình thác nước (Waterfall Model) được khắc phục bởi mô hình xoắn ốc (Spiral Model)?
Mô hình xoắn ốc giảm thiểu sự cần thiết của tài liệu hóa.
Mô hình xoắn ốc cho phép điều chỉnh yêu cầu và quản lý rủi ro qua mỗi vòng xoắn lặp lại.
Mô hình xoắn ốc không cần lập kế hoạch chi tiết trước khi bắt đầu phát triển.
Mô hình xoắn ốc yêu cầu tất cả các yêu cầu phải được xác định ngay từ đầu.
So với mô hình thác nước, mô hình RAD (Rapid Application Development) có ưu điểm nào liên quan đến thời gian phát triển?
Mô hình RAD cho phép các quá trình kiểm thử phần mềm trước khi phát hành.
Mô hình RAD giúp phát triển phần mềm với rủi ro tăng cao hơn.
Mô hình RAD cho phép hoàn thiện sản phẩm nhanh trong suốt quá trình phát triển.
Mô hình RAD cho phép hoàn thiện sản phẩm nhanh chóng bằng cách chia nhỏ các yêu cầu và phát triển song song.
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm với tiêu chí nhanh chóng xác định được yêu cầu, tạo cơ sở ký kết hợp đồng với khách hàng, thuận lợi trong việc đào tạo huấn luyện người sử dụng, bạn sẽ chọn mô hình nào sau đây?
Mô hình chữ V
Mô hình RAD
Mô hình làm bản mẫu
Mô hình xoắn ốc
Trong một hệ thống phát triển dựa trên mô hình Kỹ nghệ hướng thành phần (CBSE), nếu một thành phần trong hệ thống gặp lỗi và cần được thay thế, nhóm phát triển nên làm gì để đảm bảo tính liên tục của hệ thống?
Tạm dừng hệ thống và biên dịch lại toàn bộ mã nguồn để tích hợp thành phần mới.
Liên hệ với nhà cung cấp thành phần lỗi và chờ phiên bản cập nhật trước khi tiếp tục.
Thay thế thành phần lỗi bằng một thành phần tương thích mới mà không cần tạm dừng hệ thống, nhờ khả năng thay thế động của CBSE.
Viết lại thành phần lỗi từ đầu và chạy lại toàn bộ hệ thống để kiểm tra tính tương thích.
Khi một tổ chức muốn tích hợp một hệ thống CRM mới với hệ thống ERP hiện có mà cả hai hệ thống sử dụng các giao thức khác nhau, phương pháp nào dưới đây có thể giúp đảm bảo sự tương tác giữa các hệ thống trong kiến trúc SOA?
Sử dụng một dịch vụ trung gian (middleware) hoặc một tầng tích hợp dịch vụ để cho phép các hệ thống giao tiếp mà không cần thay đổi các hệ thống hiện có.
Tạm ngừng việc tích hợp cho đến khi tìm ra giải pháp tương thích giữa hai hệ thống.
Phát triển lại các hệ thống để chúng sử dụng cùng một giao thức giao tiếp.
Thực thi công các dữ liệu từ CRM vào ERP thông qua các kịch bản chuyển đổi dữ liệu hằng ngày.
Khi phát triển một ứng dụng nhỏ với thời gian phát triển ngắn, và nhóm phát triển muốn tận dụng tối đa các thành phần phần mềm có sẵn để sản phẩm, phương pháp nào sẽ tối ưu hơn?
Service-Oriented Architecture (SOA)
Component-based Software Engineering (CBSE)
Phát triển từ hệ thống hoàn toàn mới mà không tận dụng thành phần hoặc dịch vụ tái chế
Phát triển theo mô hình waterfall
Hai mô hình nào KHÔNG định nghĩa yêu cầu ở các giai đoạn đầu của vòng đời phát triển phần mềm?
Mô hình thác nước và RAD.
Mô hình làm bản mẫu và RAD.
Mô hình làm bản mẫu và xoắn ốc.
Mô hình thác nước và xoắn ốc.
Vòng đời phát triển phần mềm SDLC là viết tắt của từ nào sau đây?
Software Development Life Cycle.
Software Design Life Cycle.
System Development Life cycle.
System Design Life Cycle.
Phương án nào sau đây mô tả đúng về nhược điểm của mô hình xoắn ốc?
Các chức năng phụ có thể thêm vào sau.
Không phù hợp với các dự án nhỏ.
Kiểm soát tài liệu chặt chẽ.
Công việc phân tích rủi ro chiếm nhiều thời lượng.
Phương án nào sau đây nêu đúng nhược điểm lớn nhất của mô hình RAD?
Cả ba điều trên
Không tính sử dụng lại của các thành phần
Không có phản hồi từ khách hàng
Thành viên trong nhóm cần có kỹ năng và trình độ cao
Mô hình nào sau đây đòi có sự tham gia của khách hàng trong tất cả các pha của vòng đời phát triển phần mềm?
Mô hình làm bản mẫu.
Cả hai mô hình RAD và làm bản mẫu.
Mô hình phát triển nhanh RAD.
Mô hình thác nước.
Việc điều chỉnh nào của mô hình làm bản mẫu (Prototyping Model) giúp khắc phục hạn chế của thác nước khi không đáp ứng yêu cầu người dùng?
Giảm thiểu sự tham gia của khách hàng trong quá trình phát triển.
Loại bỏ sự cần thiết của tài liệu hóa chi tiết.
Tạo ra các nguyên mẫu giúp người dùng dễ dàng điều chỉnh yêu cầu trong quá trình phát triển.
Giảm thiểu thời gian phát triển và đưa ra sản phẩm nhanh hơn.
So với mô hình RAD (Rapid Application Development), mô hình thác nước (Waterfall Model) có nhược điểm nào về sự tham gia của khách hàng?
Mô hình thác nước cho phép khách hàng điều chỉnh yêu cầu thông qua các nguyên mẫu nhanh chóng.
Mô hình thác nước yêu cầu khách hàng tham gia liên tục trong suốt quá trình phát triển.
Mô hình thác nước không cho phép khách hàng thay đổi yêu cầu sau khi quá trình phát triển bắt đầu.
Mô hình thác nước không yêu cầu sự tham gia của khách hàng trong quá trình kiểm thử.
Nhận xét nào sau đây đúng về cách mô hình xoắn ốc (Spiral Model) xử lý rủi ro so với mô hình thác nước?
Mô hình xoắn ốc loại bỏ việc kiểm thử phần mềm cho đến khi sản phẩm hoàn thành.
Mô hình xoắn ốc kết hợp việc phân tích rủi ro trong mỗi chu kỳ, giúp phát hiện rủi ro tốt hơn so với mô hình thác nước.
Mô hình xoắn ốc yêu cầu tất cả các yêu cầu phải được xác định ngay từ đầu như mô hình thác nước
Mô hình xoắn ốc không cần đánh giá rủi ro trong quá trình phát triển
Nhược điểm nào của mô hình tăng trưởng (Incremental Model) có thể gây khó khăn cho việc xác định yêu cầu của người dùng?
Mô hình tăng trưởng không cho phép kiểm thử sản phẩm trước khi tất cả các phần hoàn thành.
Mô hình tăng trưởng có thể khiến người dùng khó hình dung ra sản phẩm cuối cùng do phát triển qua các phần nhỏ.
Mô hình tăng trưởng yêu cầu người dùng cung cấp tất cả các yêu cầu trước khi phát triển.
Mô hình tăng trưởng yêu cầu lập kế hoạch chi tiết cho tất cả các phần trước khi phát triển bắt đầu.
Điều gì nêu nào của mô hình thác nước (Waterfall Model) được khắc phục bởi mô hình xoắn ốc (Spiral Model)?
Mô hình thác nước yêu cầu thu thập tất cả tài liệu hóa.
Mô hình thác nước không cần phải xác định yêu cầu trước khi phát triển.
Mô hình thác nước yêu cầu tất cả các yêu cầu phải được xác định ngay từ đầu.
Mô hình xoắn ốc cho phép điều chỉnh yêu cầu và quản lý rủi ro qua mỗi vòng xoắn lặp lại.
Trong quá trình Sprint Review, nhóm phát triển đã hoàn thành hết các mục tiêu đề ra cho Sprint. Tuy nhiên, khách hàng lại yêu cầu thêm một tính năng mới chưa có trong backlog. Nhóm nên xử lý như thế nào?
Từ chối yêu cầu vì nó không nằm trong phạm vi của Sprint ban đầu.
Hoàn thành tính năng mới này trong Sprint Review để đáp ứng yêu cầu khách hàng.
Tạo một user story mới cho tính năng này và đưa vào backlog để xem xét cho các sprint sau.
Bắt đầu phát triển tính năng này ngay lập tức và gia hạn Sprint nếu cần thiết.
Nếu bạn là trưởng nhóm lập trình của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm lớn với nhiều nghiệp vụ phức tạp trong một khoảng thời gian dài và không cần quan tâm đến việc các yêu cầu của khách hàng đã được phân tích rất chi tiết và chỉ thay đổi trong một phạm vi nhất định, bạn sẽ chọn mô hình nào sau đây?
Mô hình tăng trưởng
Mô hình xoắn ốc
Mô hình RAD
Mô hình thác nước
Trong Scrum, nếu Product Owner không tham gia đầy đủ vào quá trình làm việc của nhóm, điều gì có thể xảy ra?
Sprint sẽ bị tạm dừng cho đến khi Product Owner tham gia trở lại.
Nhóm Scrum Master sẽ thay thế vai trò Product Owner và quản lý backlog.
Nhóm phát triển tự quyết định các ưu tiên sản phẩm và tiếp tục Sprint mà không cần Product Owner.
Sprint vẫn tiếp tục nhưng các yêu cầu có thể không chính xác hoặc không đáp ứng được nhu cầu khách hàng.
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm lớn với tiêu chí phát triển theo hướng mở rộng, hoàn thiện dần, có khả năng kiểm soát rủi ro ở từng mức tiến hóa, được hỗ trợ chi phí cho chuyên gia, bạn sẽ chọn mô hình nào sau đây?
Mô hình RAD
Mô hình làm bản mẫu
Mô hình xoắn ốc
Mô hình thác nước
Nếu bạn là trưởng nhóm lập trình của một công ty phần mềm và bạn cần nộp sản phẩm trong một khoảng thời gian ngắn và không cần quan tâm đến chi phí, bạn sẽ chọn mô hình nào sau đây?
Mô hình thác nước
Mô hình RAD
Mô hình xoắn ốc
Mô hình tăng trưởng
Vòng đời phát triển phần mềm SDLC là viết tắt của từ nào sau đây?
Software Design Life Cycle.
System Design Life Cycle.
Software Development Life Cycle.
System Development Life Cycle
RAD viết tắt của từ nào sau đây?
Relative Application Development
Rapid Application Development
Không từ nào
Rapid Application Document
Hai mô hình nào KHÔNG định nghĩa yêu cầu ở các giai đoạn đầu của vòng đời phát triển phần mềm?
Mô hình làm bản mẫu và xoắn ốc.
Mô hình làm bản mẫu và RAD.
Mô hình thác nước và xoắn ốc.
Mô hình thác nước và RAD.
Phương án nào sau đây mô tả đúng về ưu điểm chính của mô hình tăng trưởng?
Khách hàng có thể phản hồi sau mỗi lần tăng trưởng.
Được dùng khi cần đưa sản phẩm ra thị trường sớm.
Dễ kiểm thử và debug và được dùng khi cần đưa sản phẩm ra thị trường sớm.
Được dùng khi cần kiểm thử và debug.
Phương án nào sau đây KHÔNG nêu đúng ưu điểm của quy trình phát triển phần mềm theo mô hình thác nước?
Quá trình phát triển đơn giản nên phù hợp với những dự án có ít thay đổi.
Giảm thiểu các lỗi mắc phải trong giai đoạn thiết kế
Sửa lỗi dễ dàng và tốn ít chi phí
Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng nên dễ phân công công việc, phân bổ chi phí, giám sát công việc.
Nhận định nào sau đây đúng về ưu điểm của mô hình làm bản mẫu (Prototyping Model) so với mô hình thác nước (Waterfall Model)?
Mô hình làm bản mẫu cho phép người dùng điều chỉnh yêu cầu dựa trên nguyên mẫu trước khi sản phẩm hoàn chỉnh được phát triển.
Sản phẩm hoàn chỉnh được phát triển sau khi tài liệu hóa chi tiết như mô hình thác nước.
Mô hình làm bản mẫu không cho phép sự tham gia của khách hàng trong suốt quá trình phát triển.
Mô hình làm bản mẫu giúp giảm thời gian phát triển phần mềm so với mô hình thác nước.
So với mô hình thác nước, mô hình RAD (Rapid Application Development) có ưu điểm nào liên quan đến giai đoạn phát triển?
Mô hình RAD cho phép hoàn thiện sản phẩm nhanh chóng bằng cách chia nhỏ các yêu cầu và phát triển song song.
Mô hình RAD không cho phép hoàn thiện sản phẩm nhanh chóng.
Mô hình RAD không chia nhỏ các yêu cầu.
Mô hình RAD không phát triển song song.
So với mô hình làm bản mẫu, mô hình tiến hóa (Evolutionary Model) có ưu điểm nào trong việc xử lý các yêu cầu thay đổi?
Mô hình tiến hóa không cho phép điều chỉnh yêu cầu sau khi phát triển bắt đầu.
Mô hình tiến hóa cho phép yêu cầu thay đổi liên tục trong suốt quá trình phát triển, không chỉ dựa trên các nguyên mẫu ban đầu.
Mô hình tiến hóa không cần sự tham gia của khách hàng trong suốt quá trình phát triển.
Mô hình tiến hóa chỉ hoàn thành tất cả các yêu cầu ngay từ đầu.
Phát biểu nào sau đây mô tả đúng cách mô hình tăng trưởng (Incremental Model) giúp giảm rủi ro khi phát triển phần mềm theo thác nước?
Mô hình tăng trưởng yêu cầu tất cả các yêu cầu phải được xác định trước khi phát triển bắt đầu.
Mô hình tăng trưởng không cần tài liệu hóa mô hình thác nước.
Mô hình tăng trưởng cho phép chia hệ thống thành nhiều phần, cho phép kiểm thử sớm và điều chỉnh dựa trên phản hồi từ mỗi phần.
Mô hình tăng trưởng phát triển toàn bộ hệ thống ngay từ đầu mà không cần qua các giai đoạn lặp lại.
Nhận xét nào sau đây đúng về cách mô hình chữ V (V-Model) khắc phục nhược điểm của mô hình thác nước?
Mô hình chữ V cho phép linh hoạt quay lại các giai đoạn trước khi có thay đổi yêu cầu.
Mô hình chữ V kết hợp kiểm thử trong từng giai đoạn phát triển, giúp đảm bảo chất lượng sản phẩm.
Mô hình chữ V không yêu cầu lập kế hoạch trước.
Mô hình chữ V không cần đến sự tham gia của khách hàng trong giai đoạn kiểm thử.
Một công ty đang phát triển bản nâng cấp của một phần mềm đã được bán trên thị trường, mô hình nào sau đây thích hợp trong trường hợp này?
Cả mô hình RAD và tiến hóa
Mô hình tiến hóa
Mô hình xoắn ốc
Mô hình RAD
Trong một hệ thống phát triển theo mô hình SOA, nếu một dịch vụ quan trọng bị ngừng hoạt động do sự cố mạng, nhóm phát triển nên ưu tiên làm gì để đảm bảo rằng các dịch vụ khác vẫn tiếp tục hoạt động?
Phát triển lại dịch vụ gặp sự cố ngay lập tức và tích hợp lại vào hệ thống sau khi hoàn thành.
Tạm dừng toàn bộ hệ thống cho đến khi dịch vụ quan trọng được khôi phục hoàn toàn.
Tìm kiếm các giải pháp thủ công để thay thế chức năng của dịch vụ gặp sự cố cho đến khi mạng hoạt động trở lại.
Cấu hình hệ thống để sử dụng các dịch vụ thay thế khác, đảm bảo tính sẵn sàng và khả năng tiếp tục của các phần còn lại của hệ thống.
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm khả năng mô đun hóa cao, thời gian phát triển sản phẩm ngắn (60-90 ngày), bạn sẽ chọn mô hình nào sau đây?
Mô hình tiến hóa
Mô hình tăng trưởng
Mô hình làm bản mẫu
Mô hình RAD
Trong một dự án lớn, yêu cầu về khả năng tương tác giữa các hệ thống sử dụng các ngôn ngữ và môi trường khác nhau là rất quan trọng. Đội phát triển nên chọn mô hình nào để đảm bảo hệ thống có khả năng mở rộng và linh hoạt tốt nhất?
Chuyển đổi tất cả các hệ thống sang cùng một ngôn ngữ và môi trường để dễ quản lý
Component-based Software Engineering (CBSE)
Phát triển phần mềm từ đầu mà không sử dụng tái chế các thành phần
Service-Oriented Architecture (SOA)
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm có thể đưa vào hoạt động trong thời gian ngắn, sản phẩm chuyển giao chia thành từng phần tăng thêm theo yêu cầu chức năng, đáp ứng nhanh yêu cầu của khách hàng, bạn sẽ chọn mô hình nào sau đây?
Mô hình tăng trưởng
Mô hình tiến hóa
Mô hình làm bản mẫu
Mô hình RAD
Hoạt động nào sau đây trong tiến trình phần mềm tổng quát cung cấp báo cáo phản hồi của khách hàng?
Lập kế hoạch
Triển khai
Mô hình hóa
Giao tiếp
Mô hình nào sau đây KHÔNG phù hợp cho việc kỹ nghệ phần mềm có yêu cầu thay đổi?
Mô hình làm bản mẫu
Mô hình xoắn ốc
Mô hình thác nước
Mô hình phát triển nhanh RAD
Hai mô hình nào sau đây sẽ không thể cho ra sản phẩm đạt yêu cầu nếu không có sự tham gia của khách hàng?
Mô hình RAD & xoắn ốc.
Mô hình thác nước và xoắn ốc.
Mô hình RAD & mô hình làm bản mẫu.
Mô hình RAD & mô hình thác nước.
Mô hình nào sau đây có sự tham gia của khách hàng trong tất cả các pha của vòng đời phát triển phần mềm?
Cả hai mô hình RAD và làm bản mẫu.
Mô hình phát triển nhanh RAD.
Mô hình làm bản mẫu.
Mô hình thác nước.
Phương án nào sau đây KHÔNG nêu đúng một pha của mô hình làm bản mẫu?
Làm mịn bản mẫu
Kỹ nghệ
Thiết kế nhanh
Lập trình
Ưu điểm chính nào của mô hình làm bản mẫu (Prototyping Model) giúp khắc phục hạn chế của mô hình thác nước trong việc đáp ứng yêu cầu người dùng?
.Tạo ra các nguyên mẫu giúp người dùng dễ dàng điều chỉnh yêu cầu trong quá trình phát triển
Loại bỏ sự cần thiết của tài liệu hóa chi tiết. Giảm thiểu thời gian phát triển và đưa ra sản phẩm nhanh hơn
Giảm thiểu thời gian phát triển và đưa ra sản phẩm nhanh hơn
Giảm thiểu sự tham gia của khách hàng trong quá trình phát triển
Nhận xét nào sau đây đúng về cách mô hình xoắn ốc (Spiral Model) xử lý rủi ro so với mô hình thác nước?
Mô hình xoắn ốc yêu cầu tất cả các yêu cầu phải được xác định ngay từ đầu như mô hình thác nước.
Mô hình xoắn ốc loại bỏ việc kiểm thử phần mềm cho đến khi sản phẩm hoàn thành.
Mô hình xoắn ốc không cần đánh giá rủi ro trong quá trình phát triển.
Mô hình xoắn ốc kết hợp đánh giá rủi ro trong mỗi chu kỳ lặp, giúp quản lý rủi ro tốt hơn so với mô hình thác nước.
Nhược điểm nào của mô hình tăng trưởng (Incremental Model) có thể gây khó khăn cho việc hình dung sản phẩm cuối cùng?
Mô hình tăng trưởng yêu cầu người dùng cung cấp tất cả các yêu cầu trước khi phát triển.
Mô hình tăng trưởng không cho phép kiểm thử sản phẩm trước khi tất cả các phần hoàn thành.
Mô hình tăng trưởng không cho phép kiểm thử sản phẩm trước khi tất cả các phần hoàn thành.
Mô hình tăng trưởng có thể khiến người dùng khó hình dung ra sản phẩm cuối cùng do phát triển qua các phần nhỏ.
So với mô hình RAD (Rapid Application Development), mô hình thác nước (Waterfall Model) có nhược điểm nào về sự tham gia của khách hàng?
Mô hình thác nước không yêu cầu sự tham gia của khách hàng trong quá trình kiểm thử.
Mô hình thác nước không cho phép khách hàng thay đổi yêu cầu sau khi quá trình phát triển bắt đầu.
Mô hình thác nước yêu cầu khách hàng tham gia liên tục trong suốt quá trình phát triển.
Mô hình thác nước cho phép khách hàng điều chỉnh yêu cầu thông qua các nguyên mẫu nhanh.
So với mô hình thác nước, mô hình RAD (Rapid Application Development) có ưu điểm nào liên quan đến thời gian phát triển?
Mô hình RAD không yêu cầu sự tham gia của khách hàng trong suốt quá trình phát triển.
Mô hình RAD không yêu cầu kiểm thử phần mềm trước khi phát hành
Mô hình RAD giúp phát triển các dự án có yêu cầu rõ ràng ngay từ đầu
Mô hình RAD cho phép hoàn thiện sản phẩm nhanh chóng bằng cách chia nhỏ các yêu cầu và phát triển song song
Trong Agile, làm thế nào để nhóm phát triển đảm bảo rằng họ đang phát triển các tính năng có giá trị cao nhất trước tiên?
Ưu tiên các tính năng theo thứ tự xuất hiện trong backlog mà không cần thay đổi.
Thực hiện phân tích chi tiết và xác định các tính năng để phát triển nhất để hoàn thành trước.
Làm việc chặt chẽ với Product Owner để liên tục đánh giá và sắp xếp lại backlog dựa trên giá trị kinh doanh và phản hồi của khách hàng.
Hoàn thành tất cả các tính năng nhỏ nhờ trước, sau đó chuyển sang các tính năng lớn và phức tạp hơn.
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm nội bộ có bộ yêu cầu chi tiết kiệm, kiểm thử nghiêm ngặt, độ tin cậy cao, có nhiều sự hỗ trợ từ chuyên gia trong công phát triển, bạn sẽ chọn mô hình nào sau đây?
Mô hình sử dụng lại
Mô hình Agile
Mô hình hướng thành phần
Mô hình mã nguồn mở
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm lớn với tiêu chí phát triển theo hướng mở rộng, hoàn thiện dần, có khả năng kiểm soát rủi ro ở từng mức tiến hóa, được hỗ trợ chi phí cho chuyên gia, bạn sẽ chọn mô hình nào sau đây?
Mô hình chữ V
Mô hình xoắn ốc
Mô hình làm bản mẫu
Mô hình RAD
Nếu bạn là trưởng nhóm lập trình của một công ty phần mềm và bạn cần nộp sản phẩm trong một khoảng thời gian ngắn và không cần quan tâm đến chi phí, bạn sẽ chọn mô hình nào sau đây?
Mô hình tăng trưởng
Mô hình thác nước
Mô hình xoắn ốc
Mô hình RAD
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm vừa và nhỏ với vòng đời ngắn, bạn sẽ chọn mô hình nào sau đây?
Mô hình tăng trưởng
Mô hình làm bản mẫu
Mô hình tiến hóa
Mô hình RAD
Trong các phát biểu dưới đây, phát biểu nào là ĐÚNG?
Mô hình thác nước phù hợp nếu lịch trình phát triển dự án rất chặt chẽ.
Mô hình RAD phù hợp với phần mềm có yêu cầu về độ tin cậy cao.
Mô hình xoắn ốc phù hợp với phần mềm có yêu cầu về độ tin cậy cao.
Thông thường, chi phí cho bảo trì nhiều hơn chi phí sản xuất phần mềm.
Trong quá trình phát triển phần mềm dựa trên mô hình CBSE, nếu một thành phần quan trọng cần phải thay đổi, điều gì thường xảy ra?
Thành phần sẽ được thay thế mà không cần dừng hệ thống.
Thành phần sẽ được thay thế mà không cần dừng hệ thống.
Thành phần có thể được thay thế tự động thông qua giao thức HTTP.
Thành phần phải được biên dịch lại và tích hợp lại vào hệ thống.
Nếu bạn là quản lý dự án của một công ty phần mềm và bạn cần xây dựng một hệ thống phần mềm có thể đưa vào hoạt động trong thời gian ngắn, sản phẩm chuyển giao chia thành từng phần tăng theo yêu cầu chức năng, đáp ứng nhanh yêu cầu của khách hàng, bạn sẽ chọn mô hình nào sau đây?
Mô hình tăng trưởng
Mô hình tiến hóa
Mô hình làm bản mẫu
Mô hình RAD
Một công ty đang phát triển bản nâng cấp của một phần mềm đã được bán trên thị trường, mô hình nào sau đây thích hợp trong trường hợp này?
Cả mô hình RAD và tiến hóa
Mô hình tiến hóa
Mô hình xoắn ốc
Mô hình RAD
Phương án nào sau đây mô tả đúng về ưu điểm chính của mô hình tăng trưởng?
Khách hàng có thể phản hồi sau mỗi lần tăng trưởng.
Được dùng khi cần đưa sản phẩm ra thị trường sớm.
Dễ kiểm thử và debug và được dùng khi cần đưa sản phẩm ra thị trường sớm.
Dễ kiểm thử và debug.
