Mật độ lỗi (defect density) dùng để đo lường

Chất lượng sản phẩm cuối

Dự án phần mềm

Quá trình sản xuất

Chất lượng bảo trì

Trả lời:

Đáp án đúng: A

Mật độ lỗi (defect density) là một thước đo chất lượng phần mềm, được tính bằng số lượng lỗi trên một đơn vị kích thước phần mềm (ví dụ: số lỗi trên 1000 dòng code - KLOC). Nó được sử dụng để đánh giá hiệu quả của quá trình phát triển phần mềm và chất lượng của sản phẩm. Do đó, đáp án đúng nhất là "C. Quá trình sản xuất". Mật độ lỗi thấp cho thấy quá trình sản xuất hiệu quả và sản phẩm có chất lượng tốt hơn.

500+ câu trắc nghiệm môn Công nghệ phần mềm có lời giải chi tiết - Phần 10

Tổng hợp 500+ câu hỏi trắc nghiệm môn Công nghệ phần mềm có đáp án đầy đủ nhằm giúp các bạn dễ dàng ôn tập lại toàn bộ các kiến thức.

50 câu hỏi 60 phút

Bắt đầu thi

Câu hỏi liên quan

Câu 43:

Chọn lựa nào sau đây mô tả một yêu cầu chức năng?

Lời giải:

Đáp án đúng: C

Yêu cầu chức năng mô tả những gì hệ thống *cần phải làm*. Nó tập trung vào chức năng và hành vi của hệ thống.

* Phương án A: Đề cập đến hiệu suất (thời gian phản hồi), đây là một yêu cầu phi chức năng.
* Phương án B: Đề cập đến khả năng sử dụng và giảm lỗi, đây là một yêu cầu phi chức năng.
* Phương án C: Mô tả một chức năng cụ thể mà hệ thống phải cung cấp (cho phép người dùng nhập chi tiết chiến dịch quảng cáo). Đây là một yêu cầu chức năng.
* Phương án D: Đề cập đến thời gian nộp báo cáo, là một ràng buộc về quy trình, có thể xem là yêu cầu phi chức năng liên quan đến thời gian.

Do đó, phương án C là đáp án đúng nhất vì nó mô tả rõ ràng một chức năng mà hệ thống cần thực hiện.

Câu 44:

Cách tốt nhất để đưa tới việc xem xét việc đánh giá yêu cầu là

Lời giải:

Đáp án đúng: D

Câu hỏi này kiểm tra kiến thức về quy trình đánh giá yêu cầu trong phát triển phần mềm. Mục tiêu của việc đánh giá yêu cầu là đảm bảo rằng các yêu cầu được thu thập đầy đủ, chính xác, rõ ràng và có thể thực hiện được. Trong các lựa chọn được đưa ra, việc sử dụng danh sách kiểm tra (checklist) là phương pháp hệ thống và hiệu quả nhất để đảm bảo rằng mọi yêu cầu đều được xem xét kỹ lưỡng theo các tiêu chí đã định.

A. Kiểm tra lỗi mô hình hệ thống: Mặc dù quan trọng, nhưng việc này thường diễn ra sau khi đã có mô hình, không phải là cách chính để đánh giá yêu cầu ban đầu.

B. Nhờ khách hàng kiểm tra yêu cầu: Khách hàng đóng vai trò quan trọng trong việc xác nhận yêu cầu, nhưng họ có thể không có chuyên môn để phát hiện các vấn đề kỹ thuật hoặc tính nhất quán của yêu cầu.

C. Gởi họ tới đội thiết kế và xem họ có sự quan tâm nào không: Cách này mang tính chất thụ động và không đảm bảo rằng tất cả các yêu cầu đều được xem xét một cách hệ thống.

D. Dùng danh sách các câu hỏi kiểm tra để kiểm tra mỗi yêu cầu: Đây là cách tiếp cận chủ động và có hệ thống nhất. Danh sách kiểm tra giúp đảm bảo rằng mọi yêu cầu đều được đánh giá dựa trên các tiêu chí nhất định (ví dụ: tính rõ ràng, tính khả thi, tính nhất quán, v.v.).

Do đó, đáp án D là đáp án tốt nhất.

Câu 45:

Use-cases là một kịch bản mà mô tả

thống

Lời giải:

Đáp án đúng: A

Use case (ca sử dụng) mô tả một chuỗi các tương tác giữa người dùng (hoặc một hệ thống khác) và hệ thống phần mềm để đạt được một mục tiêu cụ thể. Nó tập trung vào việc phần mềm sẽ thực hiện *cái gì* chứ không phải *như thế nào*. Do đó, đáp án A là chính xác nhất vì nó mô tả use case như một kịch bản về cách phần mềm hoạt động trong một tình huống cụ thể từ góc độ người dùng. Các đáp án còn lại không phù hợp: B liên quan đến công cụ CASE, C liên quan đến kế hoạch xây dựng, và D liên quan đến test case, trong khi use case là mô tả chức năng từ quan điểm người dùng.

Câu 46:

Loại mô hình nào được tạo ra trong phân tích yêu cầu phần mềm

Lời giải:

Đáp án đúng: A

Trong phân tích yêu cầu phần mềm, mục tiêu chính là hiểu rõ những gì phần mềm cần phải làm. Điều này bao gồm việc mô tả các chức năng mà phần mềm cung cấp và cách phần mềm sẽ hành xử trong các tình huống khác nhau. Do đó, mô hình được tạo ra trong giai đoạn này tập trung vào chức năng và hành vi của hệ thống.

* A. Chức nĕng và hành vi: Đây là đáp án chính xác vì phân tích yêu cầu tập trung vào việc xác định chức năng mà phần mềm phải thực hiện và cách nó sẽ hành xử.
* B. Giải thuật và cấu trúc dữ liệu: Giải thuật và cấu trúc dữ liệu là những yếu tố quan trọng trong giai đoạn thiết kế, sau khi yêu cầu đã được xác định.
* C. Kiến trúc và cấu trúc: Kiến trúc và cấu trúc hệ thống cũng thuộc về giai đoạn thiết kế, liên quan đến cách các thành phần của phần mềm được tổ chức và tương tác.
* D. Tính tin cậy và tính sử dụng: Tính tin cậy và tính sử dụng là các thuộc tính chất lượng quan trọng, nhưng chúng được xem xét trong suốt quá trình phát triển, không chỉ trong giai đoạn phân tích yêu cầu.

Câu 47:

Phân tích văn phạm của bản tường thuật xử lý là bước đầu tiên tốt nhất để tạo ra

Lời giải:

Đáp án đúng: B

Phân tích văn phạm của bản tường thuật xử lý (processing narrative) giúp xác định các thành phần và mối quan hệ giữa chúng trong quá trình xử lý dữ liệu. Điều này là cơ sở để xây dựng biểu đồ dòng dữ liệu (Data Flow Diagram - DFD), một công cụ trực quan mô tả luồng dữ liệu giữa các quy trình, kho dữ liệu và các tác nhân bên ngoài.

* A. Tự điển dữ liệu: Tự điển dữ liệu mô tả các cấu trúc dữ liệu, kiểu dữ liệu và các thuộc tính của dữ liệu. Mặc dù quan trọng, nó không phải là bước đầu tiên trực tiếp từ phân tích văn phạm của bản tường thuật xử lý.
* B. Biểu đồ dòng dữ liệu: Đây là đáp án đúng. Phân tích văn phạm của bản tường thuật xử lý giúp xác định các quy trình, kho dữ liệu và luồng dữ liệu, là những thành phần cơ bản để xây dựng DFD.
* C. Biểu đồ quan hệ thực thể: Biểu đồ quan hệ thực thể (Entity-Relationship Diagram - ERD) mô tả các thực thể và mối quan hệ giữa chúng trong một hệ thống. Nó tập trung vào cấu trúc dữ liệu hơn là luồng xử lý.
* D. Biểu đồ dịch chuyển trạng thái: Biểu đồ dịch chuyển trạng thái (State Transition Diagram) mô tả các trạng thái khác nhau của một đối tượng và các chuyển đổi giữa các trạng thái đó. Nó thường được sử dụng để mô tả hành vi của một hệ thống hoặc đối tượng.

Câu 48:

Biểu đồ dòng điều khiển

Lời giải: