Sử dụng bảng lần vết giúp:

Trong phân tích yêu cầu, việc phân tách vấn đề thường được thực hiện theo hai hướng chính: tiếp cận từ trên xuống (top-down) và tiếp cận từ dưới lên (bottom-up).

• Top-down: Bắt đầu từ một bức tranh tổng thể, chia nhỏ vấn đề thành các phần nhỏ hơn, dễ quản lý hơn. Cách tiếp cận này phù hợp khi bạn có một mục tiêu rõ ràng và muốn xác định các bước cần thiết để đạt được mục tiêu đó.
• Bottom-up: Bắt đầu từ các chi tiết cụ thể, sau đó tổng hợp lại để hiểu bức tranh toàn cảnh. Cách tiếp cận này hữu ích khi bạn có nhiều thông tin chi tiết và muốn tìm ra các mối quan hệ giữa chúng.

Các lựa chọn khác không phù hợp vì:

• Horizontal và vertical thường được sử dụng trong các ngữ cảnh khác, ví dụ như phân chia trách nhiệm trong một tổ chức hoặc kiến trúc phần mềm.
• Subordinate và superordinate liên quan đến thứ bậc, không trực tiếp mô tả cách phân tách vấn đề.

Thiết kế phần mềm quan trọng vì nó đảm bảo chất lượng của sản phẩm cuối cùng. Một thiết kế tốt giúp phần mềm dễ bảo trì, dễ mở rộng, đáng tin cậy và đáp ứng được các yêu cầu của người dùng. Accuracy (độ chính xác) và Efficiency (hiệu quả) là những yếu tố quan trọng khác, nhưng chúng là kết quả của một thiết kế chất lượng. Complexity (độ phức tạp) thường là điều cần tránh trong thiết kế phần mềm.

Thiết kế tốt trong kỹ thuật phần mềm hướng đến việc giảm sự phụ thuộc lẫn nhau giữa các module (tính liên kết yếu) và tăng tính độc lập của mỗi module (tính gắn kết cao). Điều này giúp cho việc bảo trì, sửa đổi và tái sử dụng code trở nên dễ dàng hơn. Các lựa chọn khác không phải là đặc trưng cốt lõi của một thiết kế tốt.

• Phương án 1: Cho thấy sự liên kết mạnh giữa các module: Sai. Thiết kế tốt hướng đến sự liên kết yếu giữa các module.
• Phương án 2: Thực hiện tất cả yêu cầu trong phân tích: Đúng. Thiết kế cần đáp ứng đầy đủ các yêu cầu đã xác định trong giai đoạn phân tích.
• Phương án 3: Bao gồm những test case cho tất cả thành phần: Sai. Test case là một phần của quá trình kiểm thử, không phải là đặc trưng của thiết kế.
• Phương án 4: Kết hợp mã nguồn nhằm mục đích mô tả: Sai. Thiết kế mô tả cấu trúc và tương tác giữa các thành phần, không phải là mã nguồn.

Trong biểu đồ luồng dữ liệu, khi một luồng tổng thể có tính trình tự cao và đi theo những đường thẳng, nó thể hiện một luồng biến đổi (transform). Luồng biến đổi là một chuỗi các xử lý dữ liệu liên tiếp, trong đó dữ liệu được biến đổi từ dạng này sang dạng khác qua từng bước. Tính trình tự cao và đường thẳng cho thấy rõ sự liên tục và thứ tự của các bước biến đổi này.

Tại sao các lựa chọn khác không đúng:

• Liên kết thấp: Liên kết thấp đề cập đến sự độc lập giữa các module, không trực tiếp liên quan đến luồng dữ liệu trong một đoạn của biểu đồ.
• Module hóa tốt: Module hóa tốt là một khái niệm rộng hơn về thiết kế hệ thống, không chỉ đặc trưng bởi luồng dữ liệu thẳng và trình tự.
• Luồng giao dịch (transaction): Luồng giao dịch thường liên quan đến việc xử lý các giao dịch riêng biệt và có thể có nhiều nhánh hoặc rẽ nhánh, không chỉ là một luồng thẳng.

Kiểm thử tích hợp Top-down là phương pháp kiểm thử theo hướng từ trên xuống, bắt đầu từ các module mức cao nhất và dần dần tích hợp các module mức thấp hơn. Ưu điểm chính của phương pháp này là các điểm quyết định chính của hệ thống được kiểm thử sớm, giúp phát hiện và sửa lỗi ở giai đoạn đầu của quá trình phát triển. Điều này làm giảm thiểu rủi ro và chi phí sửa chữa sau này.

• Phương án 1 không đúng: Các module mức thấp vẫn cần được kiểm thử, dù là kiểm thử đơn vị hay kiểm thử tích hợp.
• Phương án 2 đúng: Như đã giải thích ở trên.
• Phương án 3 không đúng: Kiểm thử Top-down cần stubs (module giả) để thay thế cho các module mức thấp chưa được phát triển.
• Phương án 4 không đúng: Vì có một phương án đúng (phương án 2).