Những yêu cầu nào được quan tâm suốt QFD (quality function deployment)

Sơ đồ luồng dữ liệu

Lời giải:

Đáp án đúng: B

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.

Câu 35:

Biểu đồ dòng điều khiển

Lời giải:

Đáp án đúng: A

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.

Câu 36:

Loại mô hình nào không được có trong kiến trúc phần mềm

Lời giải:

Đáp án đúng: A

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ể.

Câu 37:

Khi luồng thông tin trong một đoạn của sơ đồ luồng dữ liệu thể hiện bằng một mục đơn mà bẩy một luồng dữ liệu khác theo một trong nhiều đường sẽ thể hiện

Lời giải:

Đáp án đúng: C

Câu hỏi mô tả về một luồng thông tin trong sơ đồ luồng dữ liệu (Data Flow Diagram - DFD) mà tại một điểm, luồng này rẽ ra thành nhiều luồng dữ liệu khác nhau. Đây chính là đặc điểm của luồng giao dịch (transaction).

* Luồng giao dịch (transaction): Luồng dữ liệu ban đầu xác định loại giao dịch, sau đó luồng này rẽ nhánh dựa trên loại giao dịch đó để xử lý khác nhau.
* Luồng biến đổi (transform): Luồng dữ liệu đi qua một loạt các biến đổi để tạo ra kết quả cuối cùng. Không phù hợp với mô tả rẽ nhánh.
* Liên kết thấp (Low Coupling): Là một khái niệm về thiết kế module, nói về sự phụ thuộc giữa các module khác nhau, không liên quan trực tiếp đến luồng dữ liệu.
* Module hóa tốt (Good Modularization): Cũng là một khái niệm về thiết kế module, chỉ việc chia hệ thống thành các module nhỏ, độc lập và dễ quản lý, không liên quan trực tiếp đến luồng dữ liệu.

Do đó, đáp án chính xác nhất là Luồng giao dịch (transaction).

Câu 38:

Kiểm thử tích hợp bottom-up có những thuận lợi chính

Lời giải:

Đáp án đúng: C

Kiểm thử tích hợp bottom-up (từ dưới lên) bắt đầu bằng việc kiểm thử các module cấp thấp nhất và sau đó tích hợp chúng dần lên các module cấp cao hơn. Trong quá trình này, không cần sử dụng các trình điều khiển (driver) vì các module cấp thấp đã được kiểm thử độc lập và có thể được tích hợp trực tiếp vào các module cấp cao hơn. Các module cấp cao hơn đóng vai trò là "driver" cho các module cấp thấp hơn.

* A. Những điểm quyết định chính được kiểm thử sớm: Điều này không phải là một lợi thế đặc biệt của kiểm thử tích hợp bottom-up. Việc kiểm thử các điểm quyết định sớm phụ thuộc vào thiết kế và thứ tự tích hợp, không phải là bản chất của bottom-up.
* B. Không có những driver cần được viết: Đây là một lợi thế chính của kiểm thử tích hợp bottom-up. Vì bắt đầu từ các module cấp thấp, các module cấp cao hơn sẽ đóng vai trò như các driver khi tích hợp.
* C. Không có những stub (nhánh) cần phải viết: Stub được sử dụng trong kiểm thử tích hợp top-down, không phải bottom-up.
* D. Không đòi hỏi kiểm thử hồi quy (regression): Kiểm thử hồi quy là cần thiết trong mọi loại kiểm thử tích hợp để đảm bảo các thay đổi không gây ra lỗi mới. Vì vậy, đây không phải là một lợi thế của kiểm thử tích hợp bottom-up.

Do đó, đáp án đúng là B.

Câu 39:

Cấu trúc thông tin biểu diển tổ chức nội của

Lời giải: