Những thành phần kiến trúc trong kỹ thuật sản phẩm là

Kỹ thuật đặc tả ứng dụng thuận tiện (FAST) là một phương pháp tiếp cận trong kỹ thuật phần mềm, tập trung vào việc cải thiện giao tiếp và hợp tác giữa các nhà phát triển và khách hàng. Mục tiêu chính của FAST là giúp hai bên làm việc cùng nhau một cách hiệu quả để xác định và phát triển một tập hợp các yêu cầu ban đầu cho dự án phần mềm. Điều này bao gồm việc thu thập, làm rõ và ghi lại các yêu cầu từ quan điểm của khách hàng, đồng thời đảm bảo rằng các nhà phát triển hiểu rõ những yêu cầu này. Các lựa chọn khác như xây dựng nguyên mẫu nhanh chóng (A), học công việc lẫn nhau (B), hay phát triển đặc tả phần mềm kỹ thuật (D) cũng quan trọng, nhưng không phải là mục tiêu cốt lõi và duy nhất của FAST.

QFD (Quality Function Deployment) là một phương pháp được sử dụng để chuyển đổi các yêu cầu của khách hàng (customer requirements) thành các yêu cầu kỹ thuật (technical requirements) ở mỗi giai đoạn của quá trình phát triển sản phẩm. Trong QFD, người ta quan tâm đến tất cả các loại yêu cầu, bao gồm:

* Expected requirements (Yêu cầu mong đợi): Là những yêu cầu cơ bản mà khách hàng cho là hiển nhiên phải có. Nếu không đáp ứng được những yêu cầu này, khách hàng sẽ không hài lòng.
* Normal requirements (Yêu cầu thông thường): Là những yêu cầu mà khách hàng có thể diễn đạt rõ ràng. Mức độ đáp ứng những yêu cầu này càng cao, khách hàng càng hài lòng.
* Exciting requirements (Yêu cầu gây hứng thú): Là những yêu cầu mà khách hàng không mong đợi, nhưng khi được đáp ứng sẽ tạo ra sự ngạc nhiên và thích thú, làm tăng mức độ hài lòng của khách hàng.

Như vậy, A, B, và C đều là những yêu cầu được quan tâm trong QFD. Tuy nhiên, technology requirements (D) không trực tiếp là yêu cầu từ phía khách hàng, mà là những yêu cầu về mặt kỹ thuật để đáp ứng các yêu cầu của khách hàng.

Do đó, không có đáp án đúng nhất trong các lựa chọn đã cho, nhưng A, B, C đều đúng một phần.

Sơ đồ luồng dữ liệu (Data Flow Diagram - DFD) là một công cụ mô hình hóa hệ thống thông tin, tập trung vào việc thể hiện dòng chảy của dữ liệu qua hệ thống và các xử lý biến đổi dữ liệu đó. DFD không tập trung vào mối quan hệ giữa các đối tượng dữ liệu (điều này thuộc về mô hình ERD), không chỉ ra các quyết định logic (điều này có thể được thể hiện bằng các công cụ khác như bảng quyết định hoặc cây quyết định), và không trực tiếp chỉ ra sự tương tác với các sự kiện bên ngoài (mặc dù luồng dữ liệu có thể bắt nguồn từ hoặc kết thúc ở các tác nhân bên ngoài).

Phương án A: Đưa ra hình ảnh quan hệ giữa các đối tượng dữ liệu - Sai. Đây là mục tiêu của sơ đồ quan hệ thực thể (ERD).
Phương án B: Đưa ra hình ảnh những chức năng biến đổi luồng dữ liệu - Đúng. DFD thể hiện rõ các tiến trình xử lý (functions) biến đổi dữ liệu khi nó di chuyển qua hệ thống.
Phương án C: Chỉ ra những quyết định logic chính khi chúng xuất hiện - Sai. DFD không phải là công cụ để mô tả logic nghiệp vụ chi tiết.
Phương án D: Chỉ ra sự tương tác của hệ thống với sự kiện bên ngoài - Sai. Mặc dù DFD có thể thể hiện các tác nhân (external agents) tương tác với hệ thống, mục tiêu chính của nó không phải là mô tả các sự kiện bên ngoài.

Vậy, đáp án đúng là B.

Biểu đồ dòng điều khiển (Control Flow Diagram) mô tả luồng điều khiển giữa các thành phần của một hệ thống. Nó đặc biệt hữu ích trong việc mô hình hóa giao diện người dùng (User Interface - UI) vì nó cho thấy cách người dùng tương tác với hệ thống và cách hệ thống phản hồi lại các hành động của người dùng. Do đó, đáp án D là chính xác nhất.

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

* A: Biểu đồ dòng điều khiển hữu ích cho hệ thống hướng sự kiện nhưng không nhất thiết *cần thiết* cho tất cả các hệ thống loại này.
* B: Không phải tất cả các hệ thống đều *đòi hỏi* biểu đồ dòng điều khiển. Sự cần thiết phụ thuộc vào độ phức tạp và yêu cầu của dự án.
* C: Biểu đồ dòng điều khiển không được dùng trong biểu đồ dòng dữ liệu (Data Flow Diagram), hai loại biểu đồ này thể hiện hai khía cạnh khác nhau của hệ thống.

Kiến trúc phần mềm thường được mô tả thông qua bốn loại mô hình chính:

1. Mô hình cấu trúc (Structural Model): Mô tả cấu trúc tĩnh của hệ thống, bao gồm các thành phần, kết nối và mối quan hệ giữa chúng.
2. Mô hình động (Dynamic Model): Mô tả hành vi của hệ thống trong thời gian chạy, ví dụ như các tương tác giữa các thành phần, luồng điều khiển và xử lý sự kiện.
3. Mô hình dữ liệu (Data Model): Mô tả cấu trúc và tổ chức của dữ liệu mà hệ thống sử dụng, bao gồm các thực thể, thuộc tính và mối quan hệ giữa chúng.
4. Mô hình xử lý (Process Model): Mô tả các quy trình và luồng công việc mà hệ thống thực hiện.

Như vậy, các mô hình dữ liệu, động và cấu trúc đều là những thành phần quan trọng trong kiến trúc phần mềm. Tuy nhiên, mô hình "xử lý" không được coi là một mô hình độc lập và riêng biệt, mà thường được tích hợp vào mô hình động hoặc mô hình cấu trúc tùy thuộc vào cách tiếp cận kiến trúc cụ thể.