Những nguyên lý thiết kế giao diện nào không cho phép người dùng còn điều khiển tương tác với máy tính

Theo chiến thuật kiểm nghiệm phổ biến, kiểm nghiệm tính năng tương quan với C. Phân tích yêu cầu.

Giải thích:

• Phân tích yêu cầu là giai đoạn đầu tiên trong quy trình phát triển phần mềm, nơi các yêu cầu của người dùng được thu thập, phân tích và ghi lại. Kiểm nghiệm tính năng ở giai đoạn này giúp đảm bảo rằng phần mềm được phát triển đáp ứng đúng các yêu cầu đã được xác định. Tính năng được kiểm tra tương quan với yêu cầu để xác minh rằng các tính năng được xây dựng thực sự giải quyết các nhu cầu đã nêu.

• Phân tích toàn bộ hệ thống: Kiểm nghiệm ở mức hệ thống thường được thực hiện sau khi các thành phần riêng lẻ đã được kiểm tra.

• Thiết kế: Thiết kế là giai đoạn tạo ra kế hoạch chi tiết về cách phần mềm sẽ được xây dựng. Mặc dù kiểm nghiệm có thể liên quan đến thiết kế, nhưng tính năng tương quan trực tiếp hơn với các yêu cầu.

• Mã hóa: Mã hóa là giai đoạn viết mã nguồn của phần mềm. Kiểm nghiệm trong giai đoạn này thường tập trung vào việc kiểm tra các đơn vị mã hoặc tích hợp nhỏ, không phải tính năng ở mức độ tương quan với yêu cầu.

Do đó, đáp án C là chính xác nhất.

Tiêu chuẩn đánh giá chất lượng của một thiết kế kiến trúc tập trung vào tính chức năng của hệ thống. Tính chức năng đảm bảo rằng hệ thống đáp ứng các yêu cầu và mục tiêu đã đặt ra, cung cấp các dịch vụ và hoạt động cần thiết một cách hiệu quả. Các yếu tố khác như tính truy cập, tính tin cậy, dữ liệu, điều khiển và chi tiết thực thi cũng quan trọng, nhưng tính chức năng là yếu tố cốt lõi để đánh giá một thiết kế kiến trúc.

Mô hình CMM (Capability Maturity Model) là một mô hình đánh giá mức độ trưởng thành của quy trình phát triển phần mềm của một tổ chức. Mô hình này định nghĩa 5 mức độ trưởng thành, từ mức độ thấp nhất (khởi đầu) đến mức độ cao nhất (tối ưu hóa):

• Mức 1: Khởi đầu (Initial): Quy trình phát triển phần mềm không ổn định và thường phụ thuộc vào năng lực cá nhân.
• Mức 2: Có thể lặp lại (Repeatable): Các quy trình cơ bản đã được thiết lập để có thể lặp lại thành công các dự án tương tự.
• Mức 3: Được định nghĩa (Defined): Quy trình phát triển phần mềm được chuẩn hóa, tài liệu hóa và tích hợp vào toàn bộ tổ chức.
• Mức 4: Được quản lý (Managed): Quy trình phát triển phần mềm được đo lường và kiểm soát bằng các số liệu.
• Mức 5: Tối ưu hóa (Optimizing): Quy trình phát triển phần mềm liên tục được cải tiến dựa trên các số liệu và phân tích.

Do đó, đáp án đúng là A. 5 mức độ.

Trong một dự án thành công, việc chỉ rõ những yêu cầu theo một cách thức có thể định lượng (B) là rất quan trọng. Điều này cho phép đo lường và đánh giá tiến độ, cũng như xác định liệu dự án có đáp ứng được các mục tiêu đề ra hay không. Các xem xét kỹ thuật hình thức ưu tiên trước khi kiểm thử (A) có thể quan trọng, nhưng không phải lúc nào cũng là yếu tố quyết định thành công. Việc sử dụng những nhóm kiểm thử độc lập (C) cũng có thể hữu ích, nhưng không phải là yếu tố duy nhất đảm bảo thành công. Do đó, đáp án B là phù hợp nhất.

Kiểm thử hộp trắng (white box testing) là một kỹ thuật kiểm thử phần mềm mà trong đó cấu trúc bên trong, thiết kế và cách thức hoạt động của phần mềm được biết đến và được sử dụng để thiết kế các trường hợp kiểm thử.

• Kiểm thử hồi quy (regression test): Là loại kiểm thử để đảm bảo rằng các thay đổi hoặc sửa lỗi mới không gây ra lỗi mới hoặc làm tái phát các lỗi cũ. Kiểm thử hồi quy có thể sử dụng cả kỹ thuật hộp trắng và hộp đen.

• Kiểm thử nghiệm thu (acceptance test): Là loại kiểm thử được thực hiện bởi người dùng cuối hoặc khách hàng để xác định xem phần mềm có đáp ứng các yêu cầu của họ hay không. Kiểm thử nghiệm thu thường được thực hiện bằng kỹ thuật hộp đen.

• Kiểm thử hệ thống (system test): Là loại kiểm thử được thực hiện trên toàn bộ hệ thống để đảm bảo rằng tất cả các thành phần hoạt động cùng nhau một cách chính xác. Kiểm thử hệ thống có thể sử dụng cả kỹ thuật hộp trắng và hộp đen.

Như vậy, không có đáp án nào trong các lựa chọn trên chỉ sử dụng duy nhất kỹ thuật hộp trắng.