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

Kỹ thuật Facilitated Workshops (Hội thảo có người điều phối) là phương pháp thu thập yêu cầu mà trong đó, các bên liên quan cùng tham gia vào một buổi hội thảo được điều phối bởi một người trung gian. Mục tiêu là đạt được sự đồng thuận của tất cả các bên về các yêu cầu của dự án. Các phương án còn lại không tập trung vào sự nhất trí của số đông:

• Prototype (Mẫu thử): Tạo ra một phiên bản thử nghiệm của sản phẩm để thu thập phản hồi, nhưng không nhất thiết đòi hỏi sự đồng thuận của tất cả các bên.
• Observation (Quan sát): Quan sát người dùng sử dụng sản phẩm hoặc thực hiện công việc để thu thập yêu cầu, nhưng không liên quan đến việc đạt được sự đồng thuận.
• Questionnaires & Surveys (Bảng hỏi & Khảo sát): Thu thập thông tin từ một số lượng lớn người dùng thông qua bảng hỏi, nhưng không đảm bảo sự nhất trí giữa các câu trả lời.

Phần mềm có những đặc trưng khác biệt so với các sản phẩm vật lý. Đáp án đúng là 'Không hỏng đi, thoái hóa theo thời gian' vì:

• Không hỏng đi: Phần mềm không bị hao mòn vật lý như các thiết bị, máy móc. Nó có thể được sử dụng nhiều lần mà không bị giảm chất lượng.
• Thoái hóa theo thời gian: Mặc dù không hỏng về mặt vật lý, phần mềm có thể trở nên lỗi thời hoặc không còn phù hợp do sự thay đổi của công nghệ, yêu cầu người dùng, hoặc sự xuất hiện của các phần mềm mới tốt hơn. Đây chính là sự 'thoái hóa' của phần mềm.

Các đáp án khác không chính xác vì:

• Đơn giản, dễ hiểu, hữu hình: Phần mềm không phải lúc nào cũng đơn giản và dễ hiểu, đặc biệt là các phần mềm phức tạp. Tính hữu hình cũng không phải là đặc trưng của phần mềm (vô hình).
• Hao mòn, được chế tạo theo nghĩa cổ điển: Phần mềm không hao mòn và không được 'chế tạo' theo nghĩa cổ điển như các sản phẩm vật lý.
• Được lắp ráp từ mẫu có sẵn: Mặc dù có thể sử dụng các thư viện hoặc thành phần có sẵn, nhưng phần mềm thường được phát triển, xây dựng, và tùy chỉnh chứ không chỉ đơn thuần là lắp ráp từ mẫu có sẵn.

Kiểm tra phần mềm (Software Testing) là một quá trình quan trọng để đảm bảo chất lượng của phần mềm. Mục tiêu chính của kiểm tra phần mềm bao gồm hai hoạt động chính: kiểm thử (testing) để phát hiện lỗi và tìm lỗi (debugging) để xác định nguyên nhân và vị trí của các lỗi đó.

• Xác minh (Verification) là quá trình đảm bảo rằng phần mềm đáp ứng các yêu cầu đã được chỉ định.
• Thẩm định (Validation) là quá trình đảm bảo rằng phần mềm đáp ứng nhu cầu của người dùng.
• Gỡ lỗi (Debugging) là quá trình tìm và sửa các lỗi trong phần mềm.
• Sửa lỗi (Fixing bugs) là một phần của gỡ lỗi (Debugging), nhưng không phải là mục tiêu chính của kiểm tra phần mềm.

Như vậy, đáp án chính xác nhất là "Kiểm thử và tìm lỗi", vì nó bao gồm cả hai hoạt động cốt lõi của kiểm tra phần mềm.

Câu hỏi mô tả về việc xác định các dịch vụ mà mỗi hệ con cung cấp, cùng với các ràng buộc mà chúng phải tuân thủ. Điều này chính là bản chất của thiết kế hệ con.

• Thiết kế hệ con: Tập trung vào việc chia hệ thống lớn thành các phần nhỏ hơn, độc lập tương đối (hệ con), và xác định rõ vai trò, trách nhiệm, cũng như giao diện (dịch vụ cung cấp và ràng buộc) của từng hệ con.
• Thiết kế kiến trúc: Quan tâm đến cấu trúc tổng thể của hệ thống, cách các thành phần chính tương tác với nhau, chứ không đi sâu vào chi tiết của từng hệ con.
• Thiết kế thành phần: Tương tự như thiết kế hệ con, nhưng ở mức độ chi tiết hơn, tập trung vào các thành phần nhỏ hơn trong một hệ con.
• Đặc tả trừu tượng: Là mô tả ở mức cao, không chi tiết về cách hệ thống sẽ được thực hiện, mà tập trung vào cái gì chứ không phải như thế nào.

Vì vậy, đáp án chính xác nhất là "Thiết kế hệ con".

Trong công thức bảo trì M = p(K*exp(c-d)), tham số p thường được hiểu là công việc làm (person-months, tức số tháng làm việc của một người). Các tham số khác có ý nghĩa như sau: K là một hằng số kinh nghiệm, c là một yếu tố đánh giá độ phức tạp và d là một yếu tố khác liên quan đến độ phức tạp hoặc các yếu tố ảnh hưởng đến nỗ lực bảo trì.