Phân tích giá trị được dẫn ra như là một phần của QFD (quality function deployment) nhằm xác định:

Việc thiết kế mức thành phần trước khi thiết kế dữ liệu có thể gây ra lỗi vì cấu trúc dữ liệu có ảnh hưởng lớn đến cách các thành phần được thiết kế và tương tác với nhau. Nếu thiết kế thành phần không dựa trên cấu trúc dữ liệu phù hợp, có thể dẫn đến việc phải thay đổi thiết kế thành phần sau này, gây tốn kém thời gian và công sức. Đáp án đúng nhất là đáp án 4.

Câu hỏi đề cập đến các vấn đề thiết kế giao diện người dùng (UI) phổ biến.

• Phương án 1: "Kết nối tiền sử người dùng (profile) và shortcut chức năng" - Mặc dù profile và shortcut quan trọng, đây không phải là vấn đề thiết kế chung và nổi trội nhất trong hầu hết giao diện.
• Phương án 2: "Xử lý lỗi và thời gian đáp ứng của hệ thống" - Đây là một vấn đề thiết kế chung và nổi trội. Mọi giao diện đều phải xử lý lỗi một cách thân thiện và đảm bảo thời gian phản hồi hợp lý để mang lại trải nghiệm tốt cho người dùng.
• Phương án 3: "Quyết định hiển thị hình ảnh và thiết kế icon" - Mặc dù quan trọng, đây là chi tiết cụ thể hơn và không phải là vấn đề chung và nổi trội nhất so với việc xử lý lỗi và thời gian đáp ứng.
• Phương án 4: "Không có mục nào" - Loại bỏ vì phương án 2 đúng.

Vì vậy, phương án 2 là đáp án đúng nhất vì nó bao quát một vấn đề thiết kế chung và quan trọng trong hầu hết các giao diện người dùng.

Lý do tốt nhất để sử dụng nhóm kiểm tra phần mềm độc lập là giảm thiểu mâu thuẫn về quyền lợi giữa những người phát triển và người kiểm thử. Người phát triển có thể có xu hướng bỏ qua lỗi hoặc đánh giá thấp mức độ nghiêm trọng của chúng vì họ muốn sản phẩm của mình được chấp nhận. Ngược lại, nhóm kiểm thử độc lập sẽ khách quan hơn và tập trung vào việc tìm ra lỗi để đảm bảo chất lượng phần mềm.

• Đáp án 1 không đúng vì người phát triển vẫn cần thực hiện kiểm thử đơn vị (unit testing) và kiểm thử tích hợp (integration testing).
• Đáp án 2 không đúng vì việc "kiểm tra chặt" không phải là lý do chính, mà là tính khách quan và độc lập.
• Đáp án 3 không đúng vì người kiểm thử có thể tham gia vào dự án sớm để xem xét tài liệu yêu cầu và thiết kế, giúp phát hiện lỗi sớm hơn.

Mô hình CMM (Capability Maturity Model) được phát triển để đánh giá và cải thiện 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 độ ban đầu (Initial) đến mức độ tối ưu hóa (Optimizing).

• Mức 1: Initial (Ban đầu): Quy trình hỗn loạn và không được xác định rõ ràng. Thành công phụ thuộc vào nỗ lực cá nhân.
• Mức 2: Managed (Quản lý): Các quy trình cơ bản được thiết lập để theo dõi chi phí, tiến độ và chức năng. Các quy trình này có thể lặp lại ở các dự án tương tự.
• Mức 3: Defined (Định nghĩa): Các quy trình được chuẩn hóa, ghi lại và tích hợp vào một tập hợp các quy trình chuẩn của tổ chức.
• Mức 4: Quantitatively Managed (Quản lý định lượng): Đo lường và kiểm soát quy trình bằng cách sử dụng các kỹ thuật thống kê và định lượng.
• Mức 5: Optimizing (Tối ưu hóa): Tập trung vào cải tiến quy trình liên tục thông qua việc sử dụng phản hồi và công nghệ mới.

Kiểm nghiệm tính năng tương quan (correlation testing) là một chiến thuật kiểm nghiệm phần mềm tập trung vào việc xác định các phụ thuộc và tương tác giữa các module, thành phần hoặc tính năng khác nhau của hệ thống. Mục tiêu là đảm bảo rằng các thành phần này hoạt động hài hòa và chính xác khi kết hợp với nhau. Trong các giai đoạn phát triển phần mềm, việc này thường được thực hiện sau khi phân tích yêu cầu và thiết kế đã hoàn thành, và trước khi bắt đầu mã hóa, để đảm bảo thiết kế đáp ứng được các yêu cầu tương quan giữa các chức năng. Vì vậy, kiểm nghiệm tính năng tương quan mật thiết nhất với giai đoạn phân tích yêu cầu, vì nó đảm bảo các yêu cầu đã được xác định đầy đủ và nhất quán với nhau.

Phương án 1: Phân tích toàn bộ hệ thống là một hoạt động tổng quát hơn và không đặc biệt tập trung vào các tương quan giữa các tính năng. Phương án 2: Thiết kế liên quan đến việc tạo ra kế hoạch chi tiết về cách hệ thống sẽ được xây dựng, nhưng kiểm nghiệm tính năng tương quan tập trung vào việc xác minh rằng các yêu cầu đã được phân tích chính xác. Phương án 3: Phân tích yêu cầu là giai đoạn mà các yêu cầu của hệ thống được xác định và ghi lại. Kiểm nghiệm tính năng tương quan đảm bảo rằng các yêu cầu này nhất quán và không xung đột với nhau. Do đó, đây là đáp án chính xác. Phương án 4: Mã hóa là quá trình chuyển đổi thiết kế thành mã thực thi. Kiểm nghiệm tính năng tương quan xảy ra trước giai đoạn này để đảm bảo thiết kế là chính xác.