Trắc nghiệm Công nghệ Phần mềm Bài: CÁC THƯỚC ĐO CHO XÁC ĐỊNH YÊU CẦU là một trong những đề thi thuộc Chương 6: PHA XÁC ĐỊNH YÊU CẦU trong học phần Công nghệ Phần mềm chuyên ngành Công Nghệ Thông Tin cấp độ Đại học. Đây là phần kiến thức quan trọng, tập trung vào việc hiểu và áp dụng các phương pháp định lượng để đánh giá chất lượng, tiến độ và rủi ro liên quan đến yêu cầu phần mềm, từ đó cải thiện hiệu quả của toàn bộ quy trình phát triển.
Trong bài học này, người học cần nắm vững các nội dung cốt lõi như: mục đích của việc đo lường yêu cầu, các loại thước đo phổ biến (kích thước, chất lượng, quy trình), cách tính toán và diễn giải các chỉ số (ví dụ: điểm chức năng, mật độ lỗi, độ biến động), tầm quan trọng của việc thu thập dữ liệu lịch sử, và những thách thức khi áp dụng các thước đo trong thực tế. Việc hiểu rõ các thước đo cho xác định yêu cầu sẽ trang bị cho sinh viên khả năng đánh giá khách quan, đưa ra quyết định dựa trên dữ liệu và đóng góp vào việc xây dựng phần mềm chất lượng cao.
Hãy cùng Dethitracnghiem.vn tìm hiểu về đề thi này và tham gia làm kiểm tra ngay lập tức!
Trắc nghiệm Công nghệ Phần mềm Bài: CÁC THƯỚC ĐO CHO XÁC ĐỊNH YÊU CẦU
Câu 1.Mục đích chính của việc sử dụng các thước đo (metrics) trong pha xác định yêu cầu là gì?
A. Để tự động sửa lỗi.
B. Để làm cho yêu cầu phức tạp hơn.
C. Để thay thế hoàn toàn tài liệu.
D. Để đánh giá chất lượng, tiến độ và rủi ro liên quan đến yêu cầu.
Câu 2.Thước đo nào sau đây được sử dụng để định lượng “kích thước” của phần mềm dựa trên các chức năng mà nó cung cấp từ góc nhìn của người dùng?
A. Lines of Code (LOC).
B. Cyclomatic Complexity.
C. Defect Density.
D. Function Point (Điểm chức năng).
Câu 3.Khi các yêu cầu của một dự án phần mềm liên tục thay đổi sau khi được đặc tả, thước đo nào sẽ phản ánh tình trạng này?
A. Mật độ lỗi (Defect Density).
B. Tính đầy đủ (Completeness).
C. Tính nhất quán (Consistency).
D. Độ biến động yêu cầu (Requirements Volatility).
Câu 4.Nếu một tài liệu đặc tả yêu cầu có quá nhiều câu mơ hồ hoặc không rõ ràng, thước đo nào sẽ giúp định lượng vấn đề này?
A. Số lượng Use Case.
B. Số giờ làm việc.
C. Tốc độ thay đổi.
D. Mức độ mơ hồ (Ambiguity Index).
Câu 5.Để đánh giá hiệu quả của quy trình xem xét (review) yêu cầu, thước đo nào có thể được sử dụng?
A. Tốc độ viết code.
B. Số lượng cuộc họp.
C. Số lượng tài liệu đã viết.
D. Hiệu quả phát hiện lỗi (Defect Removal Efficiency – DRE) trong quá trình xem xét.
Câu 6.Thước đo “Mật độ lỗi” (Defect Density) trong yêu cầu thường được tính bằng công thức nào?
A. Tổng số lỗi / Tổng số giờ làm việc.
B. Tổng số lỗi / Tổng số dòng code.
C. Tổng số yêu cầu / Tổng số tài liệu.
D. Số lỗi được tìm thấy trong yêu cầu / Kích thước của tài liệu yêu cầu (ví dụ: số trang, số Function Point).
Câu 7.Lợi ích chính của việc sử dụng các thước đo cho yêu cầu là gì?
A. Làm cho dự án phức tạp hơn.
B. Tăng chi phí phát triển ban đầu.
C. Kéo dài thời gian ra thị trường.
D. Cung cấp dữ liệu khách quan để ra quyết định, cải thiện quy trình và nâng cao chất lượng sản phẩm.
Câu 8.Nếu một dự án không có các thước đo được xác định rõ ràng cho pha yêu cầu, hậu quả có thể là gì?
A. Phần mềm sẽ hoàn hảo hơn.
B. Chi phí bảo trì sẽ giảm.
C. Thời gian phát triển sẽ ngắn hơn.
D. Khó khăn trong việc đánh giá tiến độ, kiểm soát chất lượng và quản lý rủi ro.
Câu 9.Thước đo “Số lượng yêu cầu” (Number of Requirements) là một thước đo về loại nào?
A. Chất lượng.
B. Hiệu suất.
C. Quy trình.
D. Kích thước.
Câu 10.Thước đo “Tính đầy đủ” (Completeness) của yêu cầu có thể được đánh giá bằng cách nào?
A. Bằng cách tính số dòng code.
B. Bằng cách đếm số lỗi được tìm thấy.
C. Bằng cách tính số giờ làm việc.
D. Bằng cách so sánh các yêu cầu với các tiêu chuẩn đã đặt ra hoặc kiểm tra xem tất cả các chức năng đã được mô tả chưa.
Câu 11.Công cụ CASE nào sau đây thường có chức năng hỗ trợ việc tính toán và theo dõi các thước đo yêu cầu?
A. Trình biên dịch mã nguồn.
B. Hệ thống kiểm soát phiên bản.
C. Công cụ kiểm thử hiệu suất.
D. Công cụ quản lý yêu cầu (Requirements Management Tools).
Câu 12.Tại sao việc thu thập dữ liệu lịch sử từ các dự án trước lại quan trọng khi sử dụng các thước đo yêu cầu?
A. Để tìm ra người chịu trách nhiệm về lỗi.
B. Để làm cho tài liệu dài hơn.
C. Để che giấu thông tin quan trọng.
D. Cung cấp cơ sở để so sánh, chuẩn hóa và cải thiện độ chính xác của các ước lượng tương lai.
Câu 13.Thước đo “Tỷ lệ thay đổi yêu cầu” (Requirement Change Rate) cho biết điều gì?
A. Số lượng yêu cầu mới được thêm vào mỗi ngày.
B. Tỷ lệ lỗi được tìm thấy trong yêu cầu.
C. Tốc độ thu thập yêu cầu.
D. Mức độ thường xuyên mà các yêu cầu được thay đổi hoặc cập nhật trong một khoảng thời gian nhất định.
Câu 14.Nếu một dự án có “tỷ lệ thay đổi yêu cầu” cao, điều này có thể dẫn đến rủi ro nào về mặt quản lý dự án?
A. Giảm chi phí dự án.
B. Dự án hoàn thành sớm hơn.
C. Chất lượng sản phẩm cao hơn.
D. Phạm vi trượt (scope creep), trễ tiến độ và vượt ngân sách.
Câu 15.Thước đo nào sau đây giúp đánh giá mức độ rõ ràng của mối liên kết giữa yêu cầu với các thành phần thiết kế, mã nguồn và kiểm thử?
A. Số lượng Use Case.
B. Tỷ lệ lỗi.
C. Tốc độ phản hồi.
D. Mức độ truy vết (Traceability).
Câu 16.Phát biểu nào sau đây **không đúng** về các thước đo cho xác định yêu cầu?
A. Chúng có thể được sử dụng để so sánh hiệu suất giữa các dự án.
B. Chúng là công cụ để cải thiện quy trình.
C. Chúng cần được diễn giải trong bối cảnh cụ thể của dự án.
D. Chúng có thể thay thế hoàn toàn nhu cầu về kinh nghiệm và trực giác của con người.
Câu 17.Nếu bạn tính “mật độ lỗi” cho tài liệu yêu cầu của một dự án là \( 0.5 \) lỗi/trang, và một dự án tương tự trước đó là \( 0.2 \) lỗi/trang. Điều này cho thấy điều gì về dự án hiện tại?
A. Dự án hiện tại có chất lượng yêu cầu tốt hơn.
B. Dự án hiện tại ít phức tạp hơn.
C. Đã tìm thấy ít lỗi hơn trong dự án hiện tại.
D. Dự án hiện tại có chất lượng yêu cầu kém hơn hoặc có nhiều lỗi hơn.
Câu 18.Thước đo “Tính nhất quán” (Consistency) của yêu cầu có thể được định lượng bằng cách nào?
A. Bằng cách đếm số dòng code.
B. Bằng cách tính số giờ làm việc.
C. Bằng cách xác định số lượng yêu cầu bị thay đổi.
D. Bằng cách phát hiện số lượng mâu thuẫn giữa các yêu cầu.
Câu 19.Một “chỉ số dẫn đầu” (Leading Indicator) trong ngữ cảnh thước đo yêu cầu là gì?
A. Chỉ số chỉ cho biết kết quả cuối cùng.
B. Chỉ số chỉ cho biết những gì đã xảy ra.
C. Chỉ số không có khả năng dự đoán.
D. Một thước đo sớm có thể dự đoán hiệu suất hoặc chất lượng trong các giai đoạn sau của dự án.
Câu 20.Thước đo “Thời gian trung bình để xử lý một yêu cầu thay đổi” (Average Time to Process a Change Request) là thước đo về loại nào?
A. Kích thước.
B. Chất lượng.
C. Hiệu suất sản phẩm.
D. Quy trình (Process Metric).
Câu 21.Để một yêu cầu được coi là “đo lường được” (measurable), điều gì là cần thiết?
A. Nó phải rất ngắn gọn.
B. Nó không được thay đổi.
C. Nó phải được viết bằng tiếng Anh.
D. Có thể định lượng hoặc định tính một cách khách quan để xác định liệu nó đã được đáp ứng hay chưa.
Câu 22.Vấn đề “subjectivity” (tính chủ quan) là một thách thức khi sử dụng các thước đo yêu cầu vì:
A. Các thước đo luôn khách quan.
B. Không có ai cần diễn giải thước đo.
C. Các thước đo tự động làm mọi thứ.
D. Việc diễn giải hoặc thu thập dữ liệu có thể bị ảnh hưởng bởi quan điểm cá nhân hoặc kinh nghiệm của người thực hiện.
Câu 23.Thước đo nào sau đây thường được sử dụng để đánh giá hiệu suất của nhóm trong việc xác định yêu cầu?
A. Số lượng tính năng được triển khai.
B. Số lượng lỗi được tìm thấy trong code.
C. Thời gian phản hồi của hệ thống.
D. Năng suất thu thập yêu cầu (ví dụ: số FP/người-tháng).
Câu 24.Khi nào thì nên tính toán và phân tích các thước đo yêu cầu trong vòng đời dự án?
A. Chỉ một lần ở cuối dự án.
B. Chỉ khi có lỗi nghiêm trọng.
C. Không cần thiết phải tính toán.
D. Thường xuyên và liên tục xuyên suốt giai đoạn xác định và quản lý yêu cầu.
Câu 25.Mục tiêu của việc “chuẩn hóa” (normalization) các thước đo yêu cầu là gì?
A. Để làm cho các thước đo phức tạp hơn.
B. Để giảm số lượng thước đo.
C. Để chỉ sử dụng một loại thước đo duy nhất.
D. Để có thể so sánh các thước đo giữa các dự án khác nhau, bất kể quy mô hay loại hình.
