Những hoạt động khung nào thường không kết hợp với những quá trình thiết kế giao diện người dùng

QFD (Quality Function Deployment) là một phương pháp được sử dụng để chuyển đổi yêu cầu của khách hàng (customer requirements) thành các thông số kỹ thuật (engineering specifications) và sau đó là các yêu cầu kỹ thuật chi tiết. Trong quá trình này, QFD đặc biệt quan tâm đến tất cả các loại yêu cầu, bao gồm cả:

• Expected requirements (Yêu cầu mong đợi): Đây là những yêu cầu cơ bản mà khách hàng cho là hiển nhiên và mong đợi sản phẩm hoặc dịch vụ phải đáp ứng. Nếu những yêu cầu này không được đáp ứng, khách hàng sẽ không hài lòng.
• Normal requirements (Yêu cầu bình thường): Đây là những yêu cầu mà khách hàng nói rõ ràng và có thể đo lường được. Việc đáp ứng những yêu cầu này sẽ làm tăng sự hài lòng của khách hàng.
• Exciting requirements (Yêu cầu thú vị): Đây là những yêu cầu vượt quá mong đợi của khách hàng và mang lại sự hài lòng cao. Chúng thường là những tính năng hoặc lợi ích bất ngờ mà khách hàng không nghĩ tới.

Vì vậy, trong QFD, tất cả các loại yêu cầu trên đều được quan tâm để đảm bảo sản phẩm hoặc dịch vụ cuối cùng đáp ứng và vượt quá mong đợi của khách hàng.

Đáp án D - "technology requirements" (yêu cầu công nghệ) không phải là một loại yêu cầu mà QFD tập trung trực tiếp vào. Mặc dù công nghệ có thể đóng vai trò quan trọng trong việc đáp ứng các yêu cầu của khách hàng, nhưng bản thân các yêu cầu công nghệ không phải là trọng tâm chính của QFD.

Sơ đồ luồng dữ liệu (Data Flow Diagram - DFD) là một công cụ mô hình hóa trực quan quan trọng trong phân tích và thiết kế hệ thống. Nó tập trung vào việc mô tả cách dữ liệu di chuyển và biến đổi trong một hệ thống hoặc quy trình nghiệp vụ. DFD không tập trung vào cấu trúc dữ liệu (quan hệ giữa các đối tượng dữ liệu), quyết định logic, hay tương tác với các sự kiện bên ngoài. Thay vào đó, nó làm nổi bật các chức năng hoặc quy trình xử lý dữ liệu và cách dữ liệu được truyền giữa các chức năng này.

• Đáp án A: Sai. Mô tả quan hệ giữa các đối tượng dữ liệu là công việc của các mô hình dữ liệu, ví dụ như sơ đồ quan hệ thực thể (ERD).
• Đáp án B: Đúng. Sơ đồ luồng dữ liệu thể hiện cách các chức năng (processes) biến đổi luồng dữ liệu (data flow).
• Đáp án C: Sai. Quyết định logic thường được mô tả bằng các công cụ khác như cây quyết định (decision tree) hoặc bảng quyết định (decision table).
• Đáp án D: Sai. Sự tương tác của hệ thống với các sự kiện bên ngoài thường được mô tả bằng sơ đồ ngữ cảnh (context diagram) hoặc sơ đồ ca sử dụng (use case diagram).

Sự toàn vẹn (consistency) giao diện ngầm định đề cập đến việc duy trì tính nhất quán trong các yếu tố giao diện người dùng trên toàn bộ ứng dụng. Điều này bao gồm việc sử dụng các kỹ thuật nhập liệu (input) tương tự trong suốt ứng dụng để người dùng không phải học lại cách sử dụng các thành phần khác nhau. Do đó, phương án A là đúng. Phương án B sai vì mỗi ứng dụng nên có một look and feel nhất quán, chứ không phải riêng biệt hoàn toàn. Phương án C đề cập đến điều hướng (navigation) nhạy với ngữ cảnh, đây cũng là một phần quan trọng của thiết kế giao diện, nhưng không trực tiếp định nghĩa sự toàn vẹn giao diện ngầm định như phương án A. Do đó, phương án A là đáp án chính xác nhất.

Mô hình phát triển phần mềm tuần tự tuyến tính (Waterfall) là một mô hình phát triển phần mềm cổ điển, trong đó các giai đoạn phát triển được thực hiện một cách tuần tự và nối tiếp nhau.

• Phương án A: Mô tả đúng về sự phổ biến của mô hình Waterfall trong quá khứ và hiện tại. Tuy nhiên, đây không phải là phát biểu hợp lý nhất.
• Phương án B: Mô hình Waterfall không phù hợp với các dự án lớn, có nhiều nhóm phát triển, vì nó thiếu tính linh hoạt và khó thích ứng với các thay đổi.
• Phương án C: Đây là phát biểu chính xác và hợp lý nhất. Mô hình Waterfall phù hợp khi các yêu cầu của dự án được xác định rõ ràng và không có khả năng thay đổi nhiều trong quá trình phát triển.
• Phương án D: Mô hình Waterfall không phải là lựa chọn tốt khi cần tạo nhanh một chương trình thực thi, vì nó đòi hỏi nhiều thời gian và công sức cho việc lập kế hoạch và phân tích yêu cầu.

Do đó, phương án C là hợp lý nhất.

Trong các nguyên tắc kiểm thử phần mềm, việc kiểm thử toàn bộ mọi trường hợp có thể có của hệ thống là bất khả thi. Số lượng các trường hợp kiểm thử có thể tăng lên theo cấp số nhân khi hệ thống trở nên phức tạp hơn. Do đó, đáp án B là nguyên tắc sai.

• A đúng vì kế hoạch kiểm thử nên bắt đầu sớm để xác định các rủi ro và vấn đề tiềm ẩn từ giai đoạn đầu.
• C đúng vì đội kiểm thử độc lập có thể đưa ra cái nhìn khách quan và tìm ra nhiều lỗi hơn so với người phát triển.
• D đúng vì nguyên tắc Pareto (80/20) áp dụng trong kiểm thử, có nghĩa là 80% các lỗi thường xuất phát từ 20% các module.