Sự toàn vẹn (consistency) giao diện ngầm định

Câu hỏi này kiểm tra kiến thức về các loại đo lường có thể thu thập được khi quan sát người dùng tương tác với hệ thống máy tính. * **Phương án A: Thời gian cho ứng dụng:** Đây không phải là một đo lường trực tiếp thu thập được từ việc quan sát người dùng. Thời gian cho ứng dụng là một đặc tính của ứng dụng, không phải là một quan sát về người dùng. * **Phương án B: Số khiếm khuyết (defect) phần mềm:** Số lượng khiếm khuyết là một đặc tính của phần mềm, không phải là một đo lường thu thập từ việc quan sát người dùng. * **Phương án C: Tính tin cậy của phần mềm:** Tương tự như trên, đây là một thuộc tính của phần mềm. * **Phương án D: Thời gian đọc tài liệu trợ giúp:** Đây là một đo lường hữu ích. Thời gian người dùng dành để đọc tài liệu trợ giúp có thể cho biết mức độ dễ sử dụng của hệ thống, sự cần thiết của tài liệu trợ giúp hoặc mức độ khó khăn của tác vụ. Vậy, đáp án đúng là D. Thời gian đọc tài liệu trợ giúp.

Độ phức tạp vòng (Cyclomatic Complexity), còn được gọi là độ phức tạp McCabe, là một độ đo phần mềm, được sử dụng để chỉ ra độ phức tạp của một chương trình. Nó định lượng số lượng các đường dẫn độc lập tuyến tính thông qua một đoạn mã nguồn. Một đường dẫn độc lập tuyến tính là một đường dẫn qua mã nguồn mà không lặp lại bất kỳ cạnh nào nhiều hơn một lần. Độ phức tạp vòng được tính bằng công thức V(G) = E - N + 2, trong đó E là số cạnh và N là số nút trong đồ thị điều khiển của chương trình. Như vậy, độ đo phức tạp vòng cung cấp thông tin về số lượng đường logic độc lập trong chương trình.

Thiết kế phần mềm tốt cần thể hiện sự kết nối lỏng lẻo (khác với kết nối mạnh mẽ) giữa các mô-đun để đảm bảo tính linh hoạt và dễ bảo trì. Thiết kế tốt phải thực hiện các yêu cầu trong mô hình phân tích, cung cấp một bức tranh hoàn chỉnh về phần mềm (cấu trúc, chức năng, tương tác), và tạo điều kiện thuận lợi cho việc kiểm thử. * **A. Sai:** Kết nối mạnh mẽ giữa các mô-đun làm giảm tính linh hoạt và khả năng bảo trì. * **B. Đúng:** Thiết kế phần mềm cần hiện thực hoá các yêu cầu đã được xác định trong giai đoạn phân tích. * **C. Sai:** Các trường hợp kiểm thử là một phần của quá trình kiểm thử, không phải là đặc trưng của một thiết kế phần mềm tốt. * **D. Đúng:** Một thiết kế tốt phải cung cấp cái nhìn toàn diện về phần mềm, bao gồm cấu trúc, chức năng và các thành phần. Tuy nhiên, phương án B đúng hơn vì nó tập trung vào việc đáp ứng yêu cầu, là mục tiêu chính của thiết kế. Phương án D mô tả một đặc điểm chung chung hơn. Vì có 2 đáp án đúng nên ở đây ta chọn đáp án sát nghĩa nhất.

Phân tích yêu cầu (Requirements Analysis) là một quá trình quan trọng trong kỹ thuật phần mềm, bao gồm các hoạt động chính sau, được thực hiện theo thứ tự logic để đảm bảo hiểu rõ và chính xác các yêu cầu của dự án: 1. **Làm rõ yêu cầu (Elicitation):** Giai đoạn này tập trung vào việc thu thập và làm rõ các yêu cầu từ các bên liên quan (stakeholders). Mục tiêu là hiểu được nhu cầu thực sự của họ, xác định các chức năng và tính năng mà hệ thống cần cung cấp. Các kỹ thuật thường được sử dụng bao gồm phỏng vấn, khảo sát, brainstorming, và phân tích tài liệu. 2. **Làm tài liệu yêu cầu (Documentation):** Sau khi các yêu cầu đã được làm rõ, chúng cần được ghi lại một cách chi tiết và có cấu trúc. Tài liệu yêu cầu (Requirements Document) đóng vai trò là cơ sở để thiết kế, phát triển và kiểm thử hệ thống. Các yêu cầu nên được mô tả rõ ràng, chính xác và dễ hiểu, bao gồm cả yêu cầu chức năng (functional requirements) và yêu cầu phi chức năng (non-functional requirements). 3. **Xem xét yêu cầu (Validation):** Sau khi tài liệu yêu cầu được hoàn thành, cần phải xem xét và xác nhận (validate) rằng các yêu cầu đã được ghi lại đầy đủ, chính xác và phù hợp với mục tiêu của dự án. Giai đoạn này giúp phát hiện và sửa chữa các lỗi, mâu thuẫn hoặc thiếu sót trong tài liệu yêu cầu, đảm bảo rằng tất cả các bên liên quan đều đồng ý với các yêu cầu đã được xác định. Dựa trên quy trình trên, đáp án đúng là D: Làm rõ yêu cầu, làm tài liệu yêu cầu, xem xét yêu cầu.

Phát biểu không đúng trong quá trình thu thập yêu cầu là "Yêu cầu luôn được biết một cách chính xác." Trong thực tế, yêu cầu thường mơ hồ, không đầy đủ và cần được làm rõ dần dần thông qua các kỹ thuật thu thập yêu cầu khác nhau. Các yêu cầu rất khó phát hiện, dễ thay đổi và cần phải thống nhất để đảm bảo chất lượng của dự án.